LinuxQuestions.org
Review your favorite Linux distribution.
Go Back   LinuxQuestions.org > Forums > Non-*NIX Forums > Programming
User Name
Password
Programming This forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.

Notices


Reply
  Search this Thread
Old 09-14-2009, 11:15 AM   #16
johnsfine
LQ Guru
 
Registered: Dec 2007
Distribution: Centos
Posts: 5,286

Rep: Reputation: 1194Reputation: 1194Reputation: 1194Reputation: 1194Reputation: 1194Reputation: 1194Reputation: 1194Reputation: 1194Reputation: 1194

Quote:
Originally Posted by bastl View Post
0x0000:0x0000, this is the address of the first instruction when you turn on or reset your computer
Nonsense. Try reading a CPU manual rather than making up reasonable sounding but incorrect information.

Quote:
NULL is never 0x0000
I think NULL in C is usually (void*)0

Quote:
NULL will always be a address different from 0x0000:0x0000
If you are using a C compiler with segmented addressing then NULL almost certainly is the same address as 0x0000:0x0000. But most of us haven't used C with segmented addressing for a long time.

Quote:
With c++ you even can't be sure that NULL from a parent is the same NULL of a child.
In C++, you usually should directly use 0 and not use NULL. The C++ standard requires that the compiler understand 0 when used to initialize or compare to a pointer means what NULL tries to be in C.

Quote:
NULL only means that it is a pointer to its self and if NULL is used for a call, instead of a function, some POPs and a ret will be added after. So every NULL you use instead of a different function type will be a different NULL !
More nonsense.
 
Old 09-14-2009, 11:47 AM   #17
orgcandman
Member
 
Registered: May 2002
Location: new hampshire
Distribution: Fedora, RHEL
Posts: 600

Rep: Reputation: 109Reputation: 109
Quote:
Originally Posted by bastl View Post
Sorry, but NULL is never 0x0000:0x0000, this is the address of the first instruction when you turn on or reset your computer and not only Intel. So you would call the first BIOS instruction with NULL - no, NULL is never 0x0000 nor (char) 0, NULL will always be a address different from 0x0000:0x0000 and With c++ you even can't be sure that NULL from a parent is the same NULL of a child. In that case you even can't search for NULL at all. In sure Linux will have an other NULL as you in your program!
And linux system always needs (char) 0 terminated strings like char *st="hallo" is one, and linux needs also the array to be 0 terminated.
NULL only means that it is a pointer to its self and if NULL is used for a call, instead of a function, some POPs and a ret will be added after. So every NULL you use instead of a different function type will be a different NULL !
This is all absolutely 100% INcorrect.

I suggest looking at the provided example code where NULL is PROVEN to be 0. Further, I suggest reading C99 section 6.3.2.3 which actually states that any integer with value 0, and cast to type (void *) will be considered the NULL pointer. The definition of the NULL pointer is a pointer which "is guaranteed to compare unequal to a pointer to any object or function." Not a pointer to self (the `this' keyword in C++).

All systems use strings terminated with a null byte. That's the definition of a string in C/C++ (again, see C99).
Not all arrays need to be null terminated. For instance, an array of integers not only doesn't need to be null terminated, it CAN'T be null terminated (how can you determine whether the value of NULL or the value of your integer is what is taking precedence). Further, there are some systems where you don't want to depend on null termination (see buffer overflow, stack enumeration with printf(), etc).

Your assumption of what happens when null is encountered is also false.
Quote:
if NULL is used for a call, instead of a function, some POPs and a ret will be added after.
Try this code then:
Code:
#include <string.h>

typedef void (*func)();
int main(int argc, char *argv[])
{
   func f = NULL;
   f();
   return 0;
}
Tell me what you get when you try to compile, and what you get when you try to execute?

Quote:
So every NULL you use instead of a different function type will be a different NULL !
This is not only wrong, but also dangerous. Are you saying that mallocs where memory allocation failed will return different results? How can you compare this with NULL? What about char *p = NULL; char *p2 = p;? Are the values different?
 
Old 09-14-2009, 01:44 PM   #18
bastl
Member
 
Registered: Sep 2003
Location: Germany/BW
Distribution: My own
Posts: 235

Rep: Reputation: 22
First I have to say your are all right at many points and what you write fits to what I've written. But also read exactly what I've written.
Quote:
Originally Posted by orgcandman View Post
I suggest looking at the provided example code where NULL is PROVEN to be 0. Further, I suggest reading C99 section 6.3.2.3 which actually states that any integer with value 0, and cast to type (void *) will be considered the NULL pointer. The definition of the NULL pointer is a pointer which "is guaranteed to compare unequal to a pointer to any object or function." Not a pointer to self (the `this' keyword in C++).
Yes, c++ has to handle NULL in all its variations, like you discrib it, but definitions are not what is code later.

Quote:
Originally Posted by orgcandman View Post
All systems use strings terminated with a null byte. That's the definition of a string in C/C++ (again, see C99).
Not all arrays need to be null terminated. For instance, an array of integers not only doesn't need to be null terminated, it CAN'T be null terminated (how can you determine whether the value of NULL or the value of your integer is what is taking precedence). Further, there are some systems where you don't want to depend on null termination (see buffer overflow, stack enumeration with printf(), etc).
I did write that linux systems need it!

Quote:
Originally Posted by orgcandman View Post
This is not only wrong, but also dangerous. Are you saying that mallocs where memory allocation failed will return different results? How can you compare this with NULL? What about char *p = NULL; char *p2 = p;? Are the values different?
If you define NULL (first occurrence) you can use that NULL in that way anywhere in that namespace. C++ takes care of that and can handle various Types of NULL!

Sorry, johnsfine if my guess, that you want to handle a system array was wrong, it's your thread so I'll be away, sorry.
 
Old 09-14-2009, 02:09 PM   #19
johnsfine
LQ Guru
 
Registered: Dec 2007
Distribution: Centos
Posts: 5,286

Rep: Reputation: 1194Reputation: 1194Reputation: 1194Reputation: 1194Reputation: 1194Reputation: 1194Reputation: 1194Reputation: 1194Reputation: 1194
Quote:
Originally Posted by bastl View Post
Sorry, johnsfine if my guess, that you want to handle a system array was wrong, it's your thread so I'll be away,
Your guess that it was my thread is also wrong.

I don't want to handle a system array, because I don't want anything in this thread. I was just answering, not asking.

The OP doesn't want to handle a system array: See the first post of the thread.

But what you said would be equally wrong for a system array. Modern 32 bit and 64 bit OS's don't use segmented addressing and 0000:0000 was the NULL address in old systems that did use segmented addressing.

BTW, notice post number 11 of this thread, where the OP said what (flawed) solution he had chosen and left the thread. After that, I was only trying (for the benefit of anyone finding this thread on some future search of the topic), perhaps pointlessly, to counter any confusion being spewed.

I don't think anyone is still here asking any question.

Last edited by johnsfine; 09-14-2009 at 02:11 PM.
 
Old 09-14-2009, 10:11 PM   #20
wje_lq
Member
 
Registered: Sep 2007
Location: Mariposa
Distribution: FreeBSD,Debian wheezy
Posts: 811

Rep: Reputation: 178Reputation: 178
While I was composing the following verbose response, others have joined in with relative sanity. Nonetheless, the following may be useful.
Quote:
Originally Posted by orgcandman View Post
FYI - on intel machines, NULL is 0. 0 might be a valid address, so using it as a 'special case' is a bad idea (notably, SV5R4 used 0 as a valid address, and linux can emulate this behavior). It is best practice to check explicitly for NULL, which the C library on your platform 'guarantees' to be correct.
Using 0 as the "special case" of a null pointer always works, with any standard C compiler on any computer. No matter what the manual says about NULL, I'll show how, at least with gcc on Linux, 0 can arguably be the better literal to use, in just a moment.
Quote:
Originally Posted by bastl View Post
NULL only means that it is a pointer to its self
No. NULL, if defined for your compiler, means (in the context of a pointer) 0, and 0 is guaranteed to be different from any pointer to an object or function, and is guaranteed to be the same value throughout your program, which also makes the following statement untrue:
Quote:
Originally Posted by bastl View Post
every NULL you use instead of a different function type will be a different NULL !
Ok, I'm going to quote from section 6.3.2.3, Pointers of the most recent C standard (C9899:1999) (but edit out the footnote numbers):
Quote:
3. An integer constant expression with the value 0, or such an expression cast to void *, is called a null pointer constant. If a null pointer constant is converted to a pointer type, the resulting pointer, called a null pointer, is guaranteed to compare unequal to any object or function.

4. Conversion of a null pointer to another pointer type yields a null pointer of that type. Any two null pointers shall compare equal.
So in standard C, 0 always works as a null pointer, it is always different from any pointer to an object or function, and all null pointers compare equal; there are no "different NULL"s.

So much for 0 as a null pointer. What about NULL as a null pointer? A standard C compiler need not have the NULL macro built-in. A standard C compiler must have the NULL macro defined in certain #include files. At least in the Linux gcc that I'm running, if your program does not contain any library #include, then NULL will not be defined. As required by the C standard, if you do any of these:
Code:
#include <locale.h>     /* C standard, section 7.11   */
#include <stddef.h>     /* C standard, section 7.17   */
#include <stdio.h>      /* C standard, section 7.19.1 */
#include <stdlib.h>     /* C standard, section 7.20   */
#include <string.h>     /* C standard, section 7.21.1 */
#include <time.h>       /* C standard, section 7.23.1 */
#include <wchar.h>      /* C standard, section 7.24.1 */
then NULL will be defined.

In my opinion, it's better to use NULL than 0 as your null pointer constant, because it's then easier to find each instance of it in your code with a text editor; 0 would yield too many false positives in your search.

But purists might argue (and this is where the "arguably" comes in from earlier in this post) that it's better to use 0 than NULL because 0 is always defined.

If you wish, you can run the following shell script to demonstrate an instance where 0 is defined as a null pointer, but NULL is not:
Code:
rm -f 1; gcc --version; cat > 1.c <<EOD; gcc -Wall 1.c -o 1; ./1
int main(void)
{
  char *pointer_1;
  char *pointer_2;

  pointer_1=0;
  pointer_2=NULL;

  return 0;
}
EOD
You'll get output similar to this:
Code:
gcc (GCC) 4.2.3
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

1.c: In function 'main':
1.c:7: error: 'NULL' undeclared (first use in this function)
1.c:7: error: (Each undeclared identifier is reported only once
1.c:7: error: for each function it appears in.)
./1.sh: line 12: ./1: No such file or directory
Hope this clarifies things a little.

Last edited by wje_lq; 09-14-2009 at 10:14 PM. Reason: almost inconsequential typo in quoting the standard
 
Old 09-15-2009, 09:02 AM   #21
orgcandman
Member
 
Registered: May 2002
Location: new hampshire
Distribution: Fedora, RHEL
Posts: 600

Rep: Reputation: 109Reputation: 109
Just a nit:
Quote:
Using 0 as the "special case" of a null pointer always works, with any standard C compiler on any computer. No matter what the manual says about NULL, I'll show how, at least with gcc on Linux, 0 can arguably be the better literal to use, in just a moment.
That's only true for C99 and newer compliant C compilers. I'm not sure if there's a provision like 6.3.2.3 that exists in earlier C standards (but I'm certainly open to the idea that I'm wrong on that one).

Regardless, lack of definition of null for a program with no includes is a pretty poor argument against something. I'd counter that with - the overhead of telling the compiler where to find the proper definition beats out any gains by letting the compiler "guess" your intent.

Anyway, it's moot. I'm done responding in this thread, since the OP hasn't returned and continuing the discussion it'll just turn into nitpick fest '09.
 
Old 09-15-2009, 11:00 AM   #22
wje_lq
Member
 
Registered: Sep 2007
Location: Mariposa
Distribution: FreeBSD,Debian wheezy
Posts: 811

Rep: Reputation: 178Reputation: 178
Quote:
Originally Posted by orgcandman View Post
it'll just turn into nitpick fest '09.
You say that like it's a bad thing. ;)
 
Old 09-22-2009, 09:20 AM   #23
richmike3
LQ Newbie
 
Registered: Sep 2009
Posts: 11

Original Poster
Rep: Reputation: 0
Hi,

I looked here to write set of functions for different types.

i'm using char*, uint8, uint16, uint32, uint64.

e.g,

printfStringArray (char** strArray)
{
while (*strArray != NULL)
{
printf ("%s\n", *strArray);
strArray++;
}
}


printfUint8Array (uint8* ui8Array)
{
while (*ui8Array != NULL)
{
printf ("%d\n", *ui8Array);
ui8Array++;
}
}

...
...
...

and so on .....

I knew that I can pass length of an array, but that is not required.

I need to check end of an array from the list.
 
Old 09-22-2009, 09:41 AM   #24
johnsfine
LQ Guru
 
Registered: Dec 2007
Distribution: Centos
Posts: 5,286

Rep: Reputation: 1194Reputation: 1194Reputation: 1194Reputation: 1194Reputation: 1194Reputation: 1194Reputation: 1194Reputation: 1194Reputation: 1194
Quote:
Originally Posted by richmike3 View Post
I looked here to write set of functions for different types.

i'm using char*, uint8, uint16, uint32, uint64.
The problem is char* has a fundamentally reserved value (NULL). Those other types have no fundamentally reserved value.

That means no char* that actually points to characters can have the value NULL. But there is no value for those other types about which you could make a corresponding statement.

In those other types, NULL would just be a questionable cast of zero. If expressed in a way that the compiler even accepts the cast, the value would just be zero. (If the compiler doesn't accept the cast, the code doesn't compile.)

Quote:
Code:
 printfUint8Array (uint8* ui8Array)
 {
  while (*ui8Array != NULL)
  {
   printf ("%d\n", *ui8Array);
   ui8Array++;
  }
 }
If (*ui8Array != NULL) compiles at all, it is just comparing the integer value to zero. I assume that zero is a legitimate value for an integer within the list and thus cannot be used correctly as an end marker for the list.

For most data types, there is no generally correct way to do what you apparently are trying to do. If your use of a specific data type is constrained enough that you can reserve a value, then you could use that reserved value to end the list. But if you want general purpose use of a data type (supporting all possible values of that type) you need to store and use the length or limit of the list.

Last edited by johnsfine; 09-22-2009 at 09:46 AM.
 
Old 09-23-2009, 02:00 AM   #25
smeezekitty
Senior Member
 
Registered: Sep 2009
Location: Washington U.S.
Distribution: M$ Windows / Debian / Ubuntu / DSL / many others
Posts: 2,339

Rep: Reputation: 231Reputation: 231Reputation: 231
NULL is 0
the computer startup code is at FFFF:0000
you probubly should use char **
this is more stable:
Code:
struct _str {
char a[50];
};
void foo(_str array[50]) { /*50 x 50 array*/
for(int h = 0;h < 50;h++){
printf("%s", array[h].str);
}
}
why is all this going on?
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
Linux-2.6.25.4 , memory violation at while executing "run_init_process(/sbin/init)" saikiran.veluri Linux - Newbie 1 07-04-2009 01:04 PM
Gentoo: Access Violation while compiling Autoconf-2.63 clintonsk Linux - Newbie 6 10-11-2008 06:28 PM
access Samba server: control violation /etc/rc.d/init.d/smb start failed Paul.Hermans Mandriva 1 07-25-2005 04:46 PM
Access Violation??? sh4k3y Linux - Software 3 03-25-2004 07:22 AM
WINE access violation problem Campitor Linux - Software 0 09-30-2003 11:24 AM

LinuxQuestions.org > Forums > Non-*NIX Forums > Programming

All times are GMT -5. The time now is 03:58 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration