From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from intma.in ([199.191.58.34]) by pp; Sun Dec 7 00:06:36 EST 2014 Received: (qmail 91141 invoked by uid 1005); 7 Dec 2014 00:06:36 -0500 Received: from adsl-99-103-73-246.dsl.sgnwmi.sbcglobal.net (HELO utsuho.znet) (brz@99.103.73.246) by intma.in with SMTP; 7 Dec 2014 00:06:36 -0500 Date: Sun, 7 Dec 2014 00:06:28 -0500 From: brz-systemd-dev@intma.in To: 9front@9front.org Subject: strchr definition Message-ID: List-ID: <9front.9front.org> X-Glyph: ➈ X-Bullshit: non-blocking private hardware standard NoSQL factory MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit I seem to be finding conflicting definitions of strchr strcat(2) char* strchr(char *s, char c) /sys/src/libc/port/strchr.c char* strchr(char *s, int c) /sys/include/libc.h:/strchr/ extern char* strchr(char*, int); So it seems like it takes an int, rather than a char. But referencing the 386 asm, this is seen. /sys/src/libc/386/strchr.s:4: MOVB c+4(FP), AX (^ Why a 16-bit register?) Is there a reason for these seemingly divergent definitions? From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-lb0-f171.google.com ([209.85.217.171]) by pp; Sun Dec 7 00:46:34 EST 2014 Received: by mail-lb0-f171.google.com with SMTP id n15so2359067lbi.2 for <9front@9front.org>; Sat, 06 Dec 2014 21:46:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=/kJXLmQgGJf6yHJfdIzflEo8effMlSgb+AEbeUNavII=; b=0tjOGg0NbsBAiNUavIOwR0NxKUOYnuG6ldO+Gg07HxGEorDYCyR1YZL6cPenlM25S1 karh6ZBkUxhGH0boLAr8Ie46mtc9RA09oowtJG37L/8wT98RuXsV+85iYJyKMF+1ZeLY YFWO/F8voKppGL5e/rAkKDqc5SgLk6PP6UNZoaiOLpD6H16aDGhGNxUv3ka+KFeeu3El fEP/hITJ1nznZnm+xdyk2GnwA85oBjPUkHW768clcBuJwwLPdTzEKVydXb3hHaitxvs0 YH7euclAgRRAB/P6vLA3ABj+ckCfjAx9baaJNCRgSEjQziI+bO8oK0MkbQHm8Q6eDhRJ xpmg== MIME-Version: 1.0 X-Received: by 10.112.181.98 with SMTP id dv2mr10503716lbc.78.1417931190251; Sat, 06 Dec 2014 21:46:30 -0800 (PST) Received: by 10.25.84.20 with HTTP; Sat, 6 Dec 2014 21:46:30 -0800 (PST) Received: by 10.25.84.20 with HTTP; Sat, 6 Dec 2014 21:46:30 -0800 (PST) In-Reply-To: References: Date: Sun, 7 Dec 2014 03:46:30 -0200 Message-ID: List-ID: <9front.9front.org> X-Glyph: ➈ X-Bullshit: optimized storage Subject: Re: [9front] strchr definition From: =?UTF-8?Q?Iruat=C3=A3_Souza?= To: 9front@9front.org Content-Type: multipart/alternative; boundary=001a11c37084e934a9050999d45c --001a11c37084e934a9050999d45c Content-Type: text/plain; charset=UTF-8 Em 07/12/2014 03:06, escreveu: > > I seem to be finding conflicting definitions of strchr > > strcat(2) > char* strchr(char *s, char c) > > /sys/src/libc/port/strchr.c > char* strchr(char *s, int c) > > /sys/include/libc.h:/strchr/ > extern char* strchr(char*, int); > > So it seems like it takes an int, rather than a char. > But referencing the 386 asm, this is seen. > /sys/src/libc/386/strchr.s:4: MOVB c+4(FP), AX > (^ Why a 16-bit register?) > Is there a reason for these seemingly divergent definitions? The 386 assembler does not do 16 bit, i.e. AX there is 32 bits long. --001a11c37084e934a9050999d45c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


Em 07/12/2014 03:06, <brz-sy= stemd-dev@intma.in> escreveu:
>
> I seem to be finding conflicting definitions of strchr
>
> strcat(2)
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 char* strchr(char *s, char c)
>
> /sys/src/libc/port/strchr.c
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 char* strchr(char *s, int c)
>
> /sys/include/libc.h:/strchr/
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 extern=C2=A0 char*=C2=A0 =C2=A0strchr(char= *, int);
>
> So it seems like it takes an int, rather than a char.
> But referencing the 386 asm, this is seen.
> /sys/src/libc/386/strchr.s:4: MOVB c+4(FP), AX
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0(^ Why a 16-bit register?)
> Is there a reason for these seemingly divergent definitions?

The 386 assembler does not do 16 bit, i.e. AX there is 32 bi= ts long.

--001a11c37084e934a9050999d45c-- From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from felloff.net ([199.191.58.38]) by pp; Sun Dec 7 08:25:56 EST 2014 Message-ID: List-ID: <9front.9front.org> X-Glyph: ➈ X-Bullshit: DOM proxy configuration browser Date: Sun, 7 Dec 2014 14:25:38 +0100 From: cinap_lenrek@felloff.net To: 9front@9front.org Subject: Re: [9front] strchr definition In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit in plan9 assembler, AX is like EAX (or RAX in 64bit mode) in intel assembler. the operand size is specified by the instruction like MOVB, MOVW, MOVL and MOVQ. in the MOVB c+4(FP), AX case, it would load a byte, zero extend it to 32bit and store it in AX. and yes, the manpage should to be fixed in this case. :) -- cinap