## Re: [sdcc-devel] Using generic Pointers...and NULL

 Re: [sdcc-devel] Using generic Pointers...and NULL From: Dr Russel Winder - 2004-03-01 10:58:28 Attachments: Message as HTML ```On Mon, 2004-03-01 at 06:05, Erik Petrich wrote: [ . . . ] > Based on your point #2, perhaps expressions like (gp =3D=3D (void *)0) sh= ould > be internally converted to (((int)gp) =3D=3D 0)? Isn't this proposal likely to cause problems. For example on an AVR a generic void * is a 24-bit value whereas an int is a 16-bit value so coercion from void * to int loses potentially critical information about the segment. --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Dr Russel Winder, Chief Technology Officer Tel: +44 20 8680 8712 OneEighty Software Ltd Fax: +44 20 8680 8453 Cygnet House, 12-14 Sydenham Road R.Winder@... Croydon, Surrey CR9 2ET, UK http://www.180sw.com ```

 [sdcc-devel] Using generic Pointers...and NULL From: Story, Lenny - 2004-02-16 20:02:32 ```Greetings, I have been noticing some funnyness when using generic pointers. I dont believe that any of this are bugs, just different consquences in using pointers with type fields. 1. Comparing to NULL performs a comparison of the type field. This then presents an issue where the pointer VALUE could be 0 but the type is not. The comparison Fails, and presents a behavior that is not expected. (or is it?) 2. It seems that because of #1 comparisons against NULL should use 0. This would perform a numeric compare rather than a pointer compare and result in correct behavior. 3. Libraries use the (void *)0 NULL, so these appear to work if used against true NULL.... 4. Should i have 4 varients of NULL ? #define XNULL (xdata void *)0 #define CNULL (code void *)0 #define INULL (idata void *)0 #define NULL (void *)0 What is the intent of comparisons against NULL in your minds ? It is possible im making a big deal out of nothing...if so, how should i be viewing this ? Thanks in advance for the clarification... -Lenny ```
 [sdcc-devel] strchr.c - Very Strange Implementation From: The Storys - 2004-02-17 03:22:38 ```greetings, I think that the strchr routine is making assumptions about the string which create alot of problems. Mainly that it assumes their is only a single Set of matches in a string. Rather than multiples. Specifically, it searches a string from the end to the front, and if this string is part of a Strtok operation, it may end up finding matching characters at the end first rather than the next available set like i belive it should. Current Implementation : /*****************************************************************/ char * strrchr (char * string, char ch) { char * start = string; while (*string++) /* find end of string */ ; /* search towards front */ while (--string != start && *string != ch) ; if (*string == ch) /* char found ? */ return( (char *)string ); return (NULL) ; } ?? Simpiler Implementation ?? /*****************************************************************/ char *strchr(char *s, char c) { char c_cur; if(!s) return NULL; c_cur = *s; while (c_cur && (c_cur != c)) c_cur = *(++s); return c_cur ? s : 0; } Of course, as always, i could just be on crack .... Anyone have ideas on this ? -Lenny ```
 Re: [sdcc-devel] strchr.c - Very Strange Implementation From: Erik Petrich - 2004-02-17 03:38:27 ```On Mon, 16 Feb 2004, The Storys wrote: > I think that the strchr routine is making assumptions about the string which > create alot of problems. Mainly that it assumes their is only a single Set > of matches in a string. Rather than multiples. > > Specifically, it searches a string from the end to the front, and if this > string is part of a Strtok operation, it may end up finding matching > characters at the end first rather than the next available set like i belive > it should. > > Current Implementation : > /*****************************************************************/ > char * strrchr (char * string, char ch) ^^^^^^^ note the double r > Of course, as always, i could just be on crack .... > > Anyone have ideas on this ? > > -Lenny strchr() searches from the beginning of the string to the end, and strrchr() searches from the end of the string to the beginning. Look in device/lib/strchr.c and you will find an implementation that works the way you expect. (Of course, after a long day/night of coding, my eyes might not notice the double r either) Erik ```
 RE: [sdcc-devel] strchr.c - Very Strange Implementation From: The Storys - 2004-02-17 04:14:01 ```OOPS. Ok i see it now... Sorry for the noise... -Lenny -----Original Message----- From: sdcc-devel-admin@... [mailto:sdcc-devel-admin@...]On Behalf Of Erik Petrich Sent: Monday, February 16, 2004 10:41 PM To: sdcc-devel@... Cc: The Storys Subject: Re: [sdcc-devel] strchr.c - Very Strange Implementation On Mon, 16 Feb 2004, The Storys wrote: > I think that the strchr routine is making assumptions about the string which > create alot of problems. Mainly that it assumes their is only a single Set > of matches in a string. Rather than multiples. > > Specifically, it searches a string from the end to the front, and if this > string is part of a Strtok operation, it may end up finding matching > characters at the end first rather than the next available set like i belive > it should. > > Current Implementation : > /*****************************************************************/ > char * strrchr (char * string, char ch) ^^^^^^^ note the double r > Of course, as always, i could just be on crack .... > > Anyone have ideas on this ? > > -Lenny strchr() searches from the beginning of the string to the end, and strrchr() searches from the end of the string to the beginning. Look in device/lib/strchr.c and you will find an implementation that works the way you expect. (Of course, after a long day/night of coding, my eyes might not notice the double r either) Erik ------------------------------------------------------- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click _______________________________________________ sdcc-devel mailing list sdcc-devel@... https://lists.sourceforge.net/lists/listinfo/sdcc-devel ```
 Re: [sdcc-devel] Using generic Pointers...and NULL From: Erik Petrich - 2004-03-01 06:08:59 ```On Mon, 16 Feb 2004, Story, Lenny wrote: > Greetings, > > I have been noticing some funnyness when using generic pointers. I dont > believe that any of this are bugs, just different consquences in using > pointers with type fields. > > 1. Comparing to NULL performs a comparison of the type field. This then > presents an issue where the pointer VALUE could be 0 but the type is not. > The comparison Fails, and presents a behavior that is not expected. (or is > it?) > > 2. It seems that because of #1 comparisons against NULL should use 0. This > would perform a numeric compare rather than a pointer compare and result in > correct behavior. > > 3. Libraries use the (void *)0 NULL, so these appear to work if used > against true NULL.... > > 4. Should i have 4 varients of NULL ? > > #define XNULL (xdata void *)0 > #define CNULL (code void *)0 > #define INULL (idata void *)0 > #define NULL (void *)0 > > > What is the intent of comparisons against NULL in your minds ? It is > possible im making a big deal out of nothing...if so, how should i be > viewing this ? > > Thanks in advance for the clarification... > -Lenny Section 6.3.2.3 of ISO/IEC 9899:1999 (this is C99; I haven't yet been able to track down a copy of the previous C standard) states that: (void *)0 is called a null pointer constant. The pointer resulting from the conversion of a null pointer constant to another pointer type is called a null pointer. Any two null pointer shall compare equal. However, the standard C environment also envisions a unified memory space. I believe SDCC's generic pointers (which provides the appearance of a unified memory space) work correctly if used exclusively. The problem seems to be with pointers to specific memory spaces. Since this is a nonstandard extension to C, we can implement anything we want, but it would be good to try to keep its spirit, if practical. Currently, if a pointer of any type is compared to a a literal generic pointer to void, the literal generic pointer will be cast to the other pointer's type before the comparison. So in the following code xdata char * xp; if (xp == (void *)0) doSomething(); if (xp == (xdata void *)0) doSomething(); both conditions are interpreted identically since the (void *)0 automatically becomes (xdata void *)0 to match xp's type. However, this does not help if a pointer is converted to a generic pointer before the comparison: xdata char * xp; char * gp; gp = xp; if (gp == (void *)0) doSomething(); if (gp == (xdata void *)0) doSomething(); These comparisons are not identical. Based on your point #2, perhaps expressions like (gp == (void *)0) should be internally converted to (((int)gp) == 0)? Erik ```
 Re: [sdcc-devel] Using generic Pointers...and NULL From: Dr Russel Winder - 2004-03-01 10:58:28 Attachments: Message as HTML ```On Mon, 2004-03-01 at 06:05, Erik Petrich wrote: [ . . . ] > Based on your point #2, perhaps expressions like (gp =3D=3D (void *)0) sh= ould > be internally converted to (((int)gp) =3D=3D 0)? Isn't this proposal likely to cause problems. For example on an AVR a generic void * is a 24-bit value whereas an int is a 16-bit value so coercion from void * to int loses potentially critical information about the segment. --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Dr Russel Winder, Chief Technology Officer Tel: +44 20 8680 8712 OneEighty Software Ltd Fax: +44 20 8680 8453 Cygnet House, 12-14 Sydenham Road R.Winder@... Croydon, Surrey CR9 2ET, UK http://www.180sw.com ```
 Re: [sdcc-devel] Using generic Pointers...and NULL From: Erik Petrich - 2004-03-01 16:10:41 ```On Mon, 1 Mar 2004, Dr Russel Winder wrote: > On Mon, 2004-03-01 at 06:05, Erik Petrich wrote: > [ . . . ] > > > Based on your point #2, perhaps expressions like (gp == (void *)0) should > > be internally converted to (((int)gp) == 0)? > > Isn't this proposal likely to cause problems. For example on an AVR a > generic void * is a 24-bit value whereas an int is a 16-bit value so > coercion from void * to int loses potentially critical information about > the segment. Well, at this point it is more of a brainstorming idea to help get some discussion going (since I think Lenny has raised a good point) than an formal proposal. Yes, the point was exactly to loose the segment information in this situation (comparison of a generic pointer with a generic void pointer literal). Another example (which should hold for either avr or mcs51 architectures): xdata char * func1(void) { return (void *)0; } code char * func2(void) { return (void *)0; } int test(int x, int y) { char * p; if (x) p = func1(); else p = func2(); switch (y) { case 1: return p == (xdata void *)0; case 2: return p == (code void *)0; default: return p == (void *)0; } } The current implementation would return: test(0,0) 0 p points to code offset 0, (void *)0 points to data offset 0 test(0,1) 0 p points to code offset 0, (xdata void *)0 points to xdata offset 0 test(0,2) 1 p points to code offset 0, (code void *)0 points to code offset 0 test(1,0) 0 p points to xdata offset 0, (void *)0 points to data offset 0 test(1,1) 1 p points to xdata offset 0, (xdata void *)0 points to xdata offset 0 test(1,2) 0 p points to xdata offset 0, (code void *)0 points to code offset 0 Comparing with the C standard definition of NULL is always false. So as Lenny mentioned in his point #4, one needs multiple definitions of NULL, which seems rather ugly to me. I would like to be able to compare a generic pointer to NULL without worrying about which memory space the null pointer was derived from. Erik ```
 Re: [sdcc-devel] Using generic Pointers...and NULL From: Erik Petrich - 2004-04-13 03:54:14 ```On Mon, 1 Mar 2004, Erik Petrich wrote: > On Mon, 16 Feb 2004, Story, Lenny wrote: > > > Greetings, > > > > I have been noticing some funnyness when using generic pointers. I dont > > believe that any of this are bugs, just different consquences in using > > pointers with type fields. > > > > 1. Comparing to NULL performs a comparison of the type field. This then > > presents an issue where the pointer VALUE could be 0 but the type is not. > > The comparison Fails, and presents a behavior that is not expected. (or is > > it?) > > > > 2. It seems that because of #1 comparisons against NULL should use 0. This > > would perform a numeric compare rather than a pointer compare and result in > > correct behavior. > > > > 3. Libraries use the (void *)0 NULL, so these appear to work if used > > against true NULL.... > > > > 4. Should i have 4 varients of NULL ? > > > > #define XNULL (xdata void *)0 > > #define CNULL (code void *)0 > > #define INULL (idata void *)0 > > #define NULL (void *)0 > > > > > > What is the intent of comparisons against NULL in your minds ? It is > > possible im making a big deal out of nothing...if so, how should i be > > viewing this ? > > > > Thanks in advance for the clarification... > > -Lenny > > Section 6.3.2.3 of ISO/IEC 9899:1999 (this is C99; I haven't yet been able > to track down a copy of the previous C standard) states that: > > (void *)0 is called a null pointer constant. > > The pointer resulting from the conversion of a null pointer constant to > another pointer type is called a null pointer. > > Any two null pointer shall compare equal. > > However, the standard C environment also envisions a unified memory space. > I believe SDCC's generic pointers (which provides the appearance of a > unified memory space) work correctly if used exclusively. The problem > seems to be with pointers to specific memory spaces. Since this is a > nonstandard extension to C, we can implement anything we want, but it > would be good to try to keep its spirit, if practical. > > Currently, if a pointer of any type is compared to a a literal generic > pointer to void, the literal generic pointer will be cast to the other > pointer's type before the comparison. So in the following code > > xdata char * xp; > > if (xp == (void *)0) doSomething(); > if (xp == (xdata void *)0) doSomething(); > > both conditions are interpreted identically since the (void *)0 > automatically becomes (xdata void *)0 to match xp's type. However, this > does not help if a pointer is converted to a generic pointer before the > comparison: > > xdata char * xp; > char * gp; > > gp = xp; > if (gp == (void *)0) doSomething(); > if (gp == (xdata void *)0) doSomething(); > > These comparisons are not identical. I've done some experiments with Keil's compiler (8051) as well as Borland's Turbo C compiler (16-bit x86, large memory model). SDCC's current behaviour, with respect to NULL pointer comparisons, appears consistent with these other compilers. In summary: 1) Any pointer (either unqualified, or qualified with some memory space storage class) can be assigned the value NULL. This pointer can be compared to the value NULL and the results will be as expected. 2) The value of a pointer qualified with some memory space storage class can be assigned to an unqualified pointer. However, when the unqualified (generic) pointer is compared to NULL, the result may be false even if a comparison of the qualified pointer with NULL returned true. So my final conclusion is that we don't need to change anything. Erik ```