By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
445,778 Members | 1,919 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 445,778 IT Pros & Developers. It's quick & easy.

ptrs validity

P: n/a
a
Hi,
I have a pointer that points to an unknown heap memory block, is it possible
to check the pointer + 3 is valid or not?
If it is impossible, how can I do the check?
Thanks
Jul 11 '06 #1
Share this Question
Share on Google+
33 Replies


P: n/a
a said:
Hi,
I have a pointer that points to an unknown heap memory block, is it
possible to check the pointer + 3 is valid or not?
No.
If it is impossible, how can I do the check?
You can't. It's impossible.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Jul 11 '06 #2

P: n/a
"a" <a@mail.comwrote:
I have a pointer that points to an unknown heap memory block, is it possible
to check the pointer + 3 is valid or not?
No.
If it is impossible, how can I do the check?
If it is impossible, it is impossible.

Richard
Jul 11 '06 #3

P: n/a
a a écrit :
Hi,
I have a pointer that points to an unknown heap memory block, is it possible
to check the pointer + 3 is valid or not?
If it is impossible, how can I do the check?
Thanks

It depends on the operating system.

Under the windows OS you can use:

IsBadReadPtr(ptr, size)

in your case would be

IsBadReadPtr(ptr,3);

Other operating systems maybe have other methods.

jacob
Jul 11 '06 #4

P: n/a
jacob navia <ja***@jacob.remcomp.frwrites:
a a écrit :
>I have a pointer that points to an unknown heap memory block, is it possible
to check the pointer + 3 is valid or not?
If it is impossible, how can I do the check?

It depends on the operating system.

Under the windows OS you can use:

IsBadReadPtr(ptr, size)

in your case would be

IsBadReadPtr(ptr,3);

Other operating systems maybe have other methods.
Or, more likely, they don't.

The trick is to keep track of this kind of information yourself. You
knew how big the pointed-to object was when you allocated it. (Unless
it was allocated in code that you don't control; in that case, things
can be a bit more complicated.)

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Jul 11 '06 #5

P: n/a
jacob navia <ja***@jacob.remcomp.frwrote:
a a écrit :
I have a pointer that points to an unknown heap memory block, is it possible
to check the pointer + 3 is valid or not?
If it is impossible, how can I do the check?

It depends on the operating system.

Under the windows OS you can use:

IsBadReadPtr(ptr, size)

in your case would be

IsBadReadPtr(ptr,3);
jacob demonstrating once more why off-topic is off-topic:

_Often_ you can use that function under MS Windows. Not always. Not that
I expect Mr. navia to understand this, but one has to cater for the
educatable newbies, doesn't one.

Also, the example as given doesn't answer the question as asked, but
I'll leave the reason for that as an exercise for the reader.
Other operating systems maybe have other methods.
Or perhaps not.

In any case, if you need to know this, you haven't done your bookkeeping
properly. You should remember how large your allocated blocks of memory
are; and if a function requires memory of a certain size, make sure that
memory passed to it is that size. Making sure of this up front is
usually a lot easier than patching up the problems when you get it
wrong, too.

Richard
Jul 11 '06 #6

P: n/a
a posted:
Hi,
I have a pointer that points to an unknown heap memory block, is it
possible to check the pointer + 3 is valid or not?
If it is impossible, how can I do the check?
Thanks

Can't be done using "conventional" means. However, if you're willing to get
your hands dirty...

(CAUTION: Bad advice starts here.)
Hijack "malloc" and keep a track of what memory is allocated, something
like:

#define malloc mallocINTERNAL

#include "stdlib.h"

#undef malloc

void *malloc( size_t const len )
{
void *p = mallocINTERNAL(len);

/* Now access something like a
linked list or a look-up table */
}
Then you could define a function which tells you whether a byte is valid:

void ValByte(char*);

--

Frederick Gotham
Jul 11 '06 #7

P: n/a
Frederick Gotham posted:

void ValByte(char*);

int ByteIsValid(char*);
--

Frederick Gotham
Jul 11 '06 #8

P: n/a

a wrote:
Hi,
I have a pointer that points to an unknown heap memory block, is it possible
to check the pointer + 3 is valid or not?
If it is impossible, how can I do the check?
Thanks
The language-lawyers will give you the disengenuous answer "No, it's
impossible kid, go away, you bother us".

Here's ELEVEN different ways to do it:

if by "valid" you mean "inside addressable memory space" you can

(1) On Unix, set up a SEGFAULT signal handler to trap bad memory
references.
(2) On most systems that have exception handling try/catch, you can
usually catch address exceptions.
(3) On Windows, and I suspect Unix/Linux, you can ask the OS for a list
of memory segments allocated to your process, and their attributes.
Search the list to see if the desired address lands inside a readble
or writeable area.

(4) On Windows, there's a APi for this, IsBadPtr() or somesuch? Or
was this only for Win16 style segments? I forget

(5) On the x86 architecture, since the 486, there's a hardware
instruction to check this, ERRR, ERRW, ERRE to check for read write or
execute addressability of a pointer.
If your C compiler can do an _emit or _asm{} block, you can use this
for a very quick, definitive and encvapsulated answer.

(6) Most linkers emit dummy tags, something like _endBSS, _endCODE,
_endDATA, symbols you can check at run-time to see if an address falls
in a particular range.

(7) Most heap implementations expose a structure with heap info, so
you can access arena->base, arena->limit, and other interesting
heap-address revealing pointers.

(8) Keep a list of all malloc()'ed blocks, this is very useful for
checking parameters and pointers and values passed to free() and
realloc() for validity.

(9) Put all your globals in a struct, so you can check addresses
against the ends of that struct for validity.

(10) On the x86 and many other architectures, you can define malloc()
to allocate a fresh, hardware checked segment for each allocation. Then
there's a way to lookup the base and limit of each segment in the
segment tables. Foolproof and free hardware array bounds checking!

(11) Redefine malloc() to pad each heap block and all unallocated
memory before and after each block and arena and unused stack with a
run of 0xDEADBEEF. if p+3 == 0xDEADBEEF you know you're addressing
past the end of a heap block.

Jul 11 '06 #9

P: n/a
Ancient_Hacker said:
>
a wrote:
>Hi,
I have a pointer that points to an unknown heap memory block, is it
possible to check the pointer + 3 is valid or not?
If it is impossible, how can I do the check?
Thanks

The language-lawyers will give you the disengenuous answer "No, it's
impossible kid, go away, you bother us".
Well, I'll buy the "no, it's impossible" part of that parody, sure. And I
certainly applaud your efforts to overcome the limitations of the language
definition in an attempt to provide a useful answer. Nevertheless...
>
Here's ELEVEN different ways to do it:

if by "valid" you mean "inside addressable memory space" you can

(1) On Unix, set up a SEGFAULT signal handler to trap bad memory
references.
Not only did the OP not specify Unix, but this is not guaranteed to work
even on that platform. For example, the library might allocate page-sized
blocks. If so, allocating a three-byte block would result in p + 3 being
invalid in C language terms but acceptable to the OS (but
comp.unix.programmer would know more about that). I just tested this by
allocating three bytes and writing to all four of them (admittedly on Linux
rather than Unix), and the write did not cause a segfault.

(2) On most systems that have exception handling try/catch, you can
usually catch address exceptions.
C doesn't have try/catch.
(3) On Windows, and I suspect Unix/Linux, you can ask the OS for a list
of memory segments allocated to your process, and their attributes.
Search the list to see if the desired address lands inside a readble
or writeable area.
How are you going to do that in a portable manner, though? The OP posted in
comp.lang.c, which suggests he wants an answer in C language terms, not a
system call which will vary from system to system.
(4) On Windows, there's a APi for this, IsBadPtr() or somesuch? Or
was this only for Win16 style segments? I forget
Right. I forget too. Which is why we refer such questions to
comp.os.ms-windows.programmer.win32 - where they are far more likely to
know the right answer.
(5) On the x86 architecture, since the 486, there's a hardware
instruction to check this, ERRR, ERRW, ERRE to check for read write or
execute addressability of a pointer.
If your C compiler can do an _emit or _asm{} block, you can use this
for a very quick, definitive and encvapsulated answer.
But the OP did not indicate that he is using an x86.
(6) Most linkers emit dummy tags, something like _endBSS, _endCODE,
_endDATA, symbols you can check at run-time to see if an address falls
in a particular range.
Does that include the implementations used on or for:

* The Mac?
* The 360 series?
* Unisys boxes?
* Concurrents?
* SHARCs?
* Cybers?
(etc)
(7) Most heap implementations expose a structure with heap info, so
you can access arena->base, arena->limit, and other interesting
heap-address revealing pointers.
See (6).
(8) Keep a list of all malloc()'ed blocks, this is very useful for
checking parameters and pointers and values passed to free() and
realloc() for validity.
This is perhaps the most portable and practical suggestion - basically
wrapping malloc with a memory accounting system. And it demonstrates that
our initial answer ("it's impossible") is actually wrong. It /can/ be done
if you're prepared to throw enough work into it, and provided everyone uses
the wrapper, and provided you recognise that it will only handle malloc'd
memory (as opposed to automatic objects) - but that's okay, because it's
all the OP asked for. Nevertheless, if someone else on the team calls
malloc directly rather than going through your wrapper, the method fails.
>
(9) Put all your globals in a struct, so you can check addresses
against the ends of that struct for validity.
And if the OP isn't using globals? I don't get this one at all.
(10) On the x86 and many other architectures, you can define malloc()
to allocate a fresh, hardware checked segment for each allocation. Then
there's a way to lookup the base and limit of each segment in the
segment tables. Foolproof and free hardware array bounds checking!
This code must run unmodified on the N4242, due Real Soon Now, for which the
hardware specs are not yet available. Suddenly this technique isn't so
foolproof.
>
(11) Redefine malloc() to pad each heap block and all unallocated
memory before and after each block and arena and unused stack with a
run of 0xDEADBEEF. if p+3 == 0xDEADBEEF you know you're addressing
past the end of a heap block.
And what if p+3 == 0xD29102933? Can you guarantee that p+3 is valid simply
because it is not 0xDEADBEEF?
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Jul 11 '06 #10

P: n/a
a wrote:
Hi,
I have a pointer that points to an unknown heap memory block, is it possible
to check the pointer + 3 is valid or not?
If it is impossible, how can I do the check?
Thanks
As others have said, this isn't possible in portable C. In particular,
if it is "unknown heap memory", that means you can't have kept track of
it by, as suggested elsethread, by wrapping *alloc and doing some
bookkeeping. If you have lots of allocations, even if you do do the
bookkeeping there is quite a bit of overhead involved if you check
pointers often.

The question that comes to me is why you want to do this? I'd suggest
that if you want to see if your program is using invalid pointers you
use one of the many tools available. Depending on your platform, you
could look into what tools like valgrind/dmalloc/electric
fence/purify/etc can tell you about misuse of pointers. If you have
questions about these tools, you should take them to a group dedicated
to your operating system, as they only work on a limited set of
operating systems, and the same tools may work differently on the
different systems anyway...

-David

Jul 11 '06 #11

P: n/a
Richard Heathfield wrote:
>
Ancient_Hacker said:

a wrote:
Hi,
I have a pointer that points to an unknown heap memory block, is it
possible to check the pointer + 3 is valid or not?
If it is impossible, how can I do the check?
Thanks
[...]
(8) Keep a list of all malloc()'ed blocks, this is very useful for
checking parameters and pointers and values passed to free() and
realloc() for validity.

This is perhaps the most portable and practical suggestion - basically
wrapping malloc with a memory accounting system. And it demonstrates that
our initial answer ("it's impossible") is actually wrong. It /can/ be done
if you're prepared to throw enough work into it, and provided everyone uses
the wrapper, and provided you recognise that it will only handle malloc'd
memory (as opposed to automatic objects) - but that's okay, because it's
all the OP asked for. Nevertheless, if someone else on the team calls
malloc directly rather than going through your wrapper, the method fails.
That's why you should call the function something along the lines of
WasThisPointerAllocatedViaMyMallocWrapper(), rather than IsPtrValid().

:-)

[...]

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h|
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:Th*************@gmail.com>

Jul 11 '06 #12

P: n/a
On Tue, 11 Jul 2006 12:20:49 GMT, Frederick Gotham
<fg*******@SPAM.comwrote:
>a posted:
>Hi,
I have a pointer that points to an unknown heap memory block, is it
possible to check the pointer + 3 is valid or not?
If it is impossible, how can I do the check?
Thanks


Can't be done using "conventional" means. However, if you're willing to get
your hands dirty...

(CAUTION: Bad advice starts here.)
Agreed.
>

Hijack "malloc" and keep a track of what memory is allocated, something
like:
There's no need to "hijack" malloc to keep track of what memory is
allocate. Just keep track.
>#define malloc mallocINTERNAL

#include "stdlib.h"

#undef malloc

void *malloc( size_t const len )
{
void *p = mallocINTERNAL(len);

/* Now access something like a
linked list or a look-up table */
}
Then you could define a function which tells you whether a byte is valid:

void ValByte(char*);
--
Al Balmer
Sun City, AZ
Jul 11 '06 #13

P: n/a
On Tue, 11 Jul 2006 13:43:34 +0000, Richard Heathfield
<in*****@invalid.invalidwrote:
>(8) Keep a list of all malloc()'ed blocks, this is very useful for
checking parameters and pointers and values passed to free() and
realloc() for validity.

This is perhaps the most portable and practical suggestion - basically
wrapping malloc with a memory accounting system. And it demonstrates that
our initial answer ("it's impossible") is actually wrong. It /can/ be done
if you're prepared to throw enough work into it, and provided everyone uses
the wrapper, and provided you recognise that it will only handle malloc'd
memory (as opposed to automatic objects) - but that's okay, because it's
all the OP asked for. Nevertheless, if someone else on the team calls
malloc directly rather than going through your wrapper, the method fails.
I can see situations where this might be useful, but in general, it
isn't needed, because other factors constrain the use of the allocated
space anyway. For example, when you allocate space to contain an array
of known size - it's easier just to make sure your array index never
gets out of range than to fool around with a list of allocated blocks.
The only time I've had a need for a malloc-wrapping (actually
replacement) method is in debugging, when the facility was provided by
third-party libraries. I haven't actually used such a package since
the DOS days.

--
Al Balmer
Sun City, AZ
Jul 11 '06 #14

P: n/a

Richard Heathfield wrote:
Not only did the OP not specify Unix, but this is not guaranteed to work
even on that platform. For example, the library might allocate page-sized
blocks. If so, allocating a three-byte block would result in p + 3 being
invalid in C language terms but acceptable to the OS (but
comp.unix.programmer would know more about that). I just tested this by
allocating three bytes and writing to all four of them (admittedly on Linux
rather than Unix), and the write did not cause a segfault.
We don't know exactly what the OP meant by "valid", but let me guess
Usually when people ask about accessing A+3, they intend to use 32-bit
instructions to manipulate 8-bit data, sometimes with pre-fetch at the
end . A very common case is CRC-ing a network packet, which can be
done very speedily if you allow a little slop. Same with some
pattern-matching operations.

Which means the last time thru the loop the code might pre-fetch up to
3 bytes past the end of data. So all they might want to know is if the
memory is readable without major kabooms.

There isnt a way I know of in the C language to do this, but if you'll
lower yourself to allow a portability hazard....

(2) On most systems that have exception handling try/catch, you can
usually catch address exceptions.

C doesn't have try/catch.
Well, disingenous at best. The two most common C compilers, gcc and vc
which together cover maybe 80% of the market, DO have try and catch.

(3) On Windows, and I suspect Unix/Linux, you can ask the OS for a list
of memory segments allocated to your process, and their attributes.
Search the list to see if the desired address lands inside a readble
or writeable area.

How are you going to do that in a portable manner, though? The OP posted in
comp.lang.c, which suggests he wants an answer in C language terms, not a
system call which will vary from system to system.
Well, for gnu and vc IIRC , you need abotu 7 lines of codee, just read
the map file and look for ".data 0x..........."

But the OP did not indicate that he is using an x86.
Seeing as that smelly architecture has more copies out there than
anything else, there's a good chance it meets the OP's needs.
>
(6) Most linkers emit dummy tags, something like _endBSS, _endCODE,
_endDATA, symbols you can check at run-time to see if an address falls
in a particular range.

Does that include the implementations used on or for:

* The Mac?
* The 360 series?
* Unisys boxes?
* Concurrents?
* SHARCs?
* Cybers?
very curious that you mention company names, instead of linker names.
The name of the ciompany has nothing to do with the linker.
All the above except for the 60-bit Cybers can run Linux and gcc and
the gcc linker.

Even on other OS's, it's nearly trivial to link in two little stubs
"low.a" and "high.a", one as the first object file, the other as the
last object file, thereby defining the beginning and end symbols for
the rare linker that doe4snt provide this information as link symbols
or in the link map file.

I don't know of a working C implementation for the 60-bit Cybers.
>
This code must run unmodified on the N4242, due Real Soon Now, for which the
hardware specs are not yet available. Suddenly this technique isn't so
foolproof.
Yep, it's a non-portable technique. Moving the code to a new system
might take, oh, two hours to rename a few API calls. Once that's done
all the bad pointers just jump out at you.

Versus stewing (as I have) for months trying to find unset pointers.

]
You decide whether it's worth porting the code.

And what if p+3 == 0xD29102933? Can you guarantee that p+3 is valid simply
because it is not 0xDEADBEEF?
.... right... it's not foolproof, but it does catch at least 3/4 the
problems. If you see DEADBEEF you know it's (probably) unused heap,
which depending on your point of view is valid (for just reading) or
invalid (for writing). if p+3 isnt DEADBEEF, well, you obviously can
read it.... writing ti may be bad.

Programming involves a lot of analog value judgements. Is it better to
catch 3/4 of the problems, or just claim it's impossible?

Is it okay to save a plane crashing by using a feature that has been
in 92% of the C compilers out there for a handful of years, even though
it's not in any standard, or do we just buy a flower-farm to send to
funerals?

Is it better to spend 2 hrs porting "non-portable" code, or wonder
forever if there's some random memory reference somewhere?

Do we give up, just because the Cyber loader which hasnt been run in
60-bit mode for over 15 years doesnt emit _End_DATA tags, or do we
document that it works on 88.8% of the systems out there?

Things arent always black and white. Many times a little openness to
shades of gray can be very helpful.

Jul 11 '06 #15

P: n/a
Ancient_Hacker said:
We don't know exactly what the OP meant by "valid",
If it points to an existing object or function, it's valid. Otherwise, it
isn't.
but let me guess
I prefer not to guess.

<snip>
>
(2) On most systems that have exception handling try/catch, you can
usually catch address exceptions.

C doesn't have try/catch.

Well, disingenous at best.
No, C doesn't have try/catch - full stop.
The two most common C compilers, gcc and vc
which together cover maybe 80% of the market, DO have try and catch.
Not when invoked in conforming mode, which is the only mode we're really
concerned with in clc.

<snip>
>>
The OP posted
in comp.lang.c, which suggests he wants an answer in C language terms,
not a system call which will vary from system to system.

Well, for gnu and vc IIRC , you need abotu 7 lines of codee, just read
the map file and look for ".data 0x..........."
All the world's Linux/Windows, hmmm? Well, actually the world is a lot
bigger than that.

>But the OP did not indicate that he is using an x86.

Seeing as that smelly architecture has more copies out there than
anything else, there's a good chance it meets the OP's needs.
If that is true, he'll get a better answer in comp.os.ms-dos.programmer or
comp.os.ms-windows.programmer.win32 or comp.os.linux.development.apps where
the platform-specific experts hang out.
(6) Most linkers emit dummy tags, something like _endBSS, _endCODE,
_endDATA, symbols you can check at run-time to see if an address falls
in a particular range.

Does that include the implementations used on or for:

* The Mac?
* The 360 series?
* Unisys boxes?
* Concurrents?
* SHARCs?
* Cybers?

very curious that you mention company names, instead of linker names.
<shrugWhatever.
The name of the ciompany has nothing to do with the linker.
And a lowly programmer typically has little or no say about which linker is
to be used on a particular platform.
All the above except for the 60-bit Cybers can run Linux and gcc and
the gcc linker.
Doesn't mean they /do/, though. I've worked on a variety of architectures
over the last 15 years, and the only ones I've met where gcc was being used
were Sparcs and x86s. Sure, it's nice to know that gcc can run on a
mainframe, but all too often it's actually running C/370 or LE 370 or some
such cruft.

<snip>
>This code must run unmodified on the N4242, due Real Soon Now, for which
the hardware specs are not yet available. Suddenly this technique isn't
so foolproof.

Yep, it's a non-portable technique. Moving the code to a new system
might take, oh, two hours to rename a few API calls. Once that's done
all the bad pointers just jump out at you.
There's a far easier way to make them jump out. Assign NULL to them.

T *p = NULL; /* give p a known-invalid value, unless you know... */
FILE *fp = fopen("foo.txt", "w"); /* ... what value to give it */

if(fp != NULL)
{
fprintf(fp, "Hello, foo\n"); /* after use... */
fclose(fp); /* ...release the resource... */
fp = NULL; /* ...and invalidate the pointer */

You decide whether it's worth porting the code.
Okay. I decide it isn't. You might decide differently, of course. That's up
to you.

>And what if p+3 == 0xD29102933? Can you guarantee that p+3 is valid
simply because it is not 0xDEADBEEF?

... right... it's not foolproof, but it does catch at least 3/4 the
problems.
Unlikely. Checking if(p + 3 == 0xDEADBEEF) is only likely to catch around
1/4000000000 of the problems.
Programming involves a lot of analog value judgements. Is it better to
catch 3/4 of the problems, or just claim it's impossible?
When you define a pointer, you know whether it's valid. Don't forget.
Following this strategy solves way more than 3/4 of the problems.

<snip>

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Jul 11 '06 #16

P: n/a
"Ancient_Hacker" <gr**@comcast.netwrites:
Richard Heathfield wrote:
[...]
[attribution lost]
(2) On most systems that have exception handling try/catch, you can
usually catch address exceptions.

C doesn't have try/catch.

Well, disingenous at best. The two most common C compilers, gcc and vc
which together cover maybe 80% of the market, DO have try and catch.
Incorrect.

gcc is actually a collection of compilers for several different
languages. The gcc C compiler does not, as far as I know, implement
try and catch as an extension to the C language. The gcc C++ compiler
does, of course, implement try and catch -- but that's because it's a
C++ compiler. I'm guessing the same applies to vc.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Jul 11 '06 #17

P: n/a

Keith Thompson wrote:
"Ancient_Hacker" <gr**@comcast.netwrites:
The two most common C compilers, gcc and vc
which together cover maybe 80% of the market, DO have try and catch.

Incorrect.
gcc is actually a collection of compilers for several different
languages.
Nice hair-splitting. When you type "gcc", what compiler do you get?
The gcc C compiler does not, as far as I know, implement
try and catch as an extension to the C language.
It has since version 3.3, June 2003. We're now in July, 2006, at
version 4.1. Your info is about three years out of date.
I'm guessing the same applies to vc.

Nice try, but some of us have VC and don't have to guess and get the
facts right.

Jul 11 '06 #18

P: n/a
"Ancient_Hacker" <gr**@comcast.netwrites:
Keith Thompson wrote:
> The gcc C compiler does not, as far as I know, implement
try and catch as an extension to the C language.

It has since version 3.3, June 2003. We're now in July, 2006, at
version 4.1. Your info is about three years out of date.
Can you cite a section of the GCC manual that talks about try and
catch in a C context? I don't see anything about it in the "C
Extensions" chapter, which is the obvious place for it. I do
see some references in an Objective C or C++ context, but nothing
related to C.
--
Bite me! said C.
Jul 11 '06 #19

P: n/a

Richard Heathfield wrote:
Ancient_Hacker said:
We don't know exactly what the OP meant by "valid",

If it points to an existing object or function, it's valid. Otherwise, it
isn't.
This might be helpful, I yell this at my son about once a year. It
helps: You're not the center of the universe. Other people have
different definitions, some of them just as valid in their context.
When you're responding to a human being, it's helpful to try to
interpret their words as they mean them, not as you do.
Well, for gnu and vc IIRC , you need abotu 7 lines of codee, just read
the map file and look for ".data 0x..........."

All the world's Linux/Windows, hmmm? Well, actually the world is a lot
bigger than that.
Ding Ding ding, we have a winner for the most disengenous comment this
year.

What market share do you suspect Linux+Unix+Windows have?
Probably 80% plus.

What market share do linkers have that do NOT print out a map file that
indicates the size of each segment?

I've never seen one that didnt. Let's be generous and say 1% of
linkers can't be asked to print out a map file with this basic info.

So I'm getting beat up for only covering 80 to 99% of the cases. Shame
on me.

Jul 11 '06 #20

P: n/a
On 2006-07-11, Ancient_Hacker <gr**@comcast.netwrote:
>
Keith Thompson wrote:
>"Ancient_Hacker" <gr**@comcast.netwrites:
The two most common C compilers, gcc and vc
which together cover maybe 80% of the market, DO have try and catch.

Incorrect.
>gcc is actually a collection of compilers for several different
languages.

Nice hair-splitting. When you type "gcc", what compiler do you get?
That's determined by the file extension. If you pass .c, you'll get a
C compiler; if you pass .cpp, you'll get a C++ compiler. I believe that
if you pass some .o files and nothing else, you'll get a linker.

Of course, that can be overridden by command-line parameters.
>
> The gcc C compiler does not, as far as I know, implement
try and catch as an extension to the C language.

It has since version 3.3, June 2003. We're now in July, 2006, at
version 4.1. Your info is about three years out of date.
I can't imagine what use Keith would have for modern information on
GNU C; on this group he seems more concerned with ISO C.
I'm guessing the same applies to vc.

Nice try, but some of us have VC and don't have to guess and get the
facts right.
You poor soul.

--
Andrew Poelstra <http://www.wpsoftware.net/projects/>
To email me, use "apoelstra" at the above domain.
"You people hate mathematics." -- James Harris
Jul 11 '06 #21

P: n/a
Ancient_Hacker wrote:
Keith Thompson wrote:
"Ancient_Hacker" <gr**@comcast.netwrites:
The two most common C compilers, gcc and vc
which together cover maybe 80% of the market, DO have try and catch.
Incorrect.
gcc is actually a collection of compilers for several different
languages.

Nice hair-splitting. When you type "gcc", what compiler do you get?
The gcc C compiler does not, as far as I know, implement
try and catch as an extension to the C language.

It has since version 3.3, June 2003. We're now in July, 2006, at
version 4.1. Your info is about three years out of date.
Lots of people are using older than that. We use 3.2.3 at work. In a
big organization, upgrading compiler versions without really good
reason is expensive.

I don't see it in 4.1.1 docs here:
http://gcc.gnu.org/onlinedocs/gcc-4....l#C-Extensions

Do you have a reference for it? Not saying it isn't so, but I don't
see it.

-David

Jul 11 '06 #22

P: n/a
"Ancient_Hacker" <gr**@comcast.netwrites:
Keith Thompson wrote:
>"Ancient_Hacker" <gr**@comcast.netwrites:
The two most common C compilers, gcc and vc
which together cover maybe 80% of the market, DO have try and catch.

Incorrect.
>gcc is actually a collection of compilers for several different
languages.

Nice hair-splitting. When you type "gcc", what compiler do you get?
It depends on the extension on the filename. "gcc tmp.c" compiles C.
"gcc tmp.C" or "gcc "tmp.cc" compiles C++. "gcc -c tmp.adb" compiles
Ada (if that option is installed).
> The gcc C compiler does not, as far as I know, implement
try and catch as an extension to the C language.

It has since version 3.3, June 2003. We're now in July, 2006, at
version 4.1. Your info is about three years out of date.
I don't think so:
================================
% gcc --version
gcc (GCC) 4.0.2
Copyright (C) 2005 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.

% cat tmp.c
int try;
int catch;
% gcc -c tmp.c
% cat tmp.C
int try;
int catch;
% gcc -c tmp.C
tmp.C:1: error: expected unqualified-id before 'try'
tmp.C:2: error: expected unqualified-id before 'catch'
================================

When I compile as C, "try" and "catch" are not treated as keywords.
When I compile as C++, they are. Furthermore, the "C Extensions"
section of the gcc documentation doesn't mention "try", "catch", or
exception handling.

You claim that gcc supports try and catch as an extension when
compiling C. Can you provide a sample program that uses this
extension, and a command line that will compile it?
I'm guessing the same applies to vc.

Nice try, but some of us have VC and don't have to guess and get the
facts right.
I have gcc, and I didn't have to guess to get the fact right. I'm
going to stick with my guess about vc for now.

In any case, the real point as far as this newsgroup is concerned is
that try and catch are not part of the standard C language. Any C
compiler *could* provide them as an extension, as long as it uses a
syntax that doesn't break any strictly conforming C program and/or
provides a conforming mode in which the extension is disabled. gcc
*could* provide try and catch as an extension (it has plenty of other
extensions), but even if it did, any code that used that extension
would not be portable.

(I think lcc-win32, which is not a C++ compiler, does support try and
catch or something similar, so it's certainly possible.)

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Jul 11 '06 #23

P: n/a
"Ancient_Hacker" <gr**@comcast.netwrites:
Richard Heathfield wrote:
>Ancient_Hacker said:
We don't know exactly what the OP meant by "valid",

If it points to an existing object or function, it's valid. Otherwise, it
isn't.

This might be helpful, I yell this at my son about once a year. It
helps: You're not the center of the universe. Other people have
different definitions, some of them just as valid in their context.
When you're responding to a human being, it's helpful to try to
interpret their words as they mean them, not as you do.
You're not yelling at your son. You're having a discussion in a
public newsgroup. Many of the other participants happen to be experts
in the C programming language.

Richard's proposed definition of "valid" seems perfectly reasonable.
If the OP wants to jump in and explain what he really meant, he's free
to do so.
Well, for gnu and vc IIRC , you need abotu 7 lines of codee, just read
the map file and look for ".data 0x..........."

All the world's Linux/Windows, hmmm? Well, actually the world is a lot
bigger than that.

Ding Ding ding, we have a winner for the most disengenous comment this
year.

What market share do you suspect Linux+Unix+Windows have?
Probably 80% plus.

What market share do linkers have that do NOT print out a map file that
indicates the size of each segment?

I've never seen one that didnt. Let's be generous and say 1% of
linkers can't be asked to print out a map file with this basic info.

So I'm getting beat up for only covering 80 to 99% of the cases. Shame
on me.
Yes.

We discuss the C programming language here, not "market share".

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Jul 11 '06 #24

P: n/a
Ancient_Hacker wrote:
>
Keith Thompson wrote:
[...]
The gcc C compiler does not, as far as I know, implement
try and catch as an extension to the C language.

It has since version 3.3, June 2003. We're now in July, 2006, at
version 4.1. Your info is about three years out of date.

I'm guessing the same applies to vc.

Nice try, but some of us have VC and don't have to guess and get the
facts right.
Strange, neither my gcc nor VC recognize "try".

gcc tells me:
foo.c: In function `main':
foo.c:6: `try' undeclared (first use in this function)
VC tells me:
foo.c
foo.c(6) : error C2065: 'try' : undeclared identifier
Yet, if I tell the compilers to use C++ mode, they take it.

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h|
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:Th*************@gmail.com>
Jul 11 '06 #25

P: n/a
Keith Thompson wrote:
"Ancient_Hacker" <gr**@comcast.netwrites:
>Richard Heathfield wrote:
[...]
[attribution lost]
>>>(2) On most systems that have exception handling try/catch, you can
usually catch address exceptions.
C doesn't have try/catch.
Well, disingenous at best. The two most common C compilers, gcc and vc
which together cover maybe 80% of the market, DO have try and catch.

Incorrect.

gcc is actually a collection of compilers for several different
languages. The gcc C compiler does not, as far as I know, implement
try and catch as an extension to the C language. The gcc C++ compiler
does, of course, implement try and catch -- but that's because it's a
C++ compiler. I'm guessing the same applies to vc.
Actually, MS VC++ implements _try as an extension to C. However, I
believe you are correct about gcc.
--
Flash Gordon, living in interesting times.
Web site - http://home.flash-gordon.me.uk/
comp.lang.c posting guidelines and intro:
http://clc-wiki.net/wiki/Intro_to_clc
Jul 11 '06 #26

P: n/a
On 11 Jul 2006 12:21:50 -0700, "Ancient_Hacker" <gr**@comcast.net>
wrote:
>
Richard Heathfield wrote:
>Ancient_Hacker said:
We don't know exactly what the OP meant by "valid",

If it points to an existing object or function, it's valid. Otherwise, it
isn't.

This might be helpful, I yell this at my son about once a year. It
helps: You're not the center of the universe. Other people have
different definitions, some of them just as valid in their context.
When you're responding to a human being, it's helpful to try to
interpret their words as they mean them, not as you do.
Well, for gnu and vc IIRC , you need abotu 7 lines of codee, just read
the map file and look for ".data 0x..........."

All the world's Linux/Windows, hmmm? Well, actually the world is a lot
bigger than that.

Ding Ding ding, we have a winner for the most disengenous comment this
year.

What market share do you suspect Linux+Unix+Windows have?
Probably 80% plus.
<OTNot by a long way. For a counterexample in one of the smaller
markets, last year there were four times as many cellphones sold as
PCs.
>
What market share do linkers have that do NOT print out a map file that
indicates the size of each segment?

I've never seen one that didnt. Let's be generous and say 1% of
linkers can't be asked to print out a map file with this basic info.

So I'm getting beat up for only covering 80 to 99% of the cases. Shame
on me.
--
Al Balmer
Sun City, AZ
Jul 11 '06 #27

P: n/a
Keith Thompson wrote:
"Ancient_Hacker" <gr**@comcast.netwrites:
Keith Thompson wrote:
gcc is actually a collection of compilers for several different
languages.
Nice hair-splitting. When you type "gcc", what compiler do you get?

It depends on the extension on the filename. "gcc tmp.c" compiles C.
"gcc tmp.C" or "gcc "tmp.cc" compiles C++. "gcc -c tmp.adb" compiles
Ada (if that option is installed).
I seem to recall that it doesn't build properly unless you use g++,
because it doesn't link against the correct libraries. Compilation
isn't a problem though.


Brian
Jul 11 '06 #28

P: n/a
"Default User" <de***********@yahoo.comwrites:
Keith Thompson wrote:
>"Ancient_Hacker" <gr**@comcast.netwrites:
Keith Thompson wrote:
>gcc is actually a collection of compilers for several different
languages.

Nice hair-splitting. When you type "gcc", what compiler do you get?

It depends on the extension on the filename. "gcc tmp.c" compiles C.
"gcc tmp.C" or "gcc "tmp.cc" compiles C++. "gcc -c tmp.adb" compiles
Ada (if that option is installed).

I seem to recall that it doesn't build properly unless you use g++,
because it doesn't link against the correct libraries. Compilation
isn't a problem though.
<OT>
I believe you're right. I probably should have used "gcc -c" for all
three examples. (The g++ command is similar to the gcc command,
except that it adds all the necessary arguments to link C++
correctly.)
</OT>

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Jul 11 '06 #29

P: n/a
Keith Thompson wrote:
"Default User" <de***********@yahoo.comwrites:
I seem to recall that it doesn't build properly unless you use g++,
because it doesn't link against the correct libraries. Compilation
isn't a problem though.

<OT>
I believe you're right. I probably should have used "gcc -c" for all
three examples. (The g++ command is similar to the gcc command,
except that it adds all the necessary arguments to link C++
correctly.)
</OT>
<OTOT>
That jibes with my recollection. It's one of those standard questions
that comes up on comp.lang.c++.
</OTOT>

Brian
Jul 11 '06 #30

P: n/a
On 11 Jul 2006 09:10:31 -0700, in comp.lang.c , "Ancient_Hacker"
<gr**@comcast.netwrote:
>
Richard Heathfield wrote:
>>
C doesn't have try/catch.

Well, disingenous at best. The two most common C compilers, gcc and vc
which together cover maybe 80% of the market, DO have try and catch.
No, they don't.

g++ and VC++ do, but they're not C compilers.

--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan
Jul 11 '06 #31

P: n/a
On 11 Jul 2006 12:13:01 -0700, in comp.lang.c , "Ancient_Hacker"
<gr**@comcast.netwrote:
>
Keith Thompson wrote:
>"Ancient_Hacker" <gr**@comcast.netwrites:
The two most common C compilers, gcc and vc
which together cover maybe 80% of the market, DO have try and catch.

Incorrect.
>gcc is actually a collection of compilers for several different
languages.

Nice hair-splitting. When you type "gcc", what compiler do you get?
either gcc or g++, depending on the code suffix. Whats your point,
genius?
> The gcc C compiler does not, as far as I know, implement
try and catch as an extension to the C language.

It has since version 3.3, June 2003. We're now in July, 2006, at
version 4.1. Your info is about three years out of date.
[mark@thelinux src]# gcc try.c
try.c: In function 'main':
try.c:4: error: 'try' undeclared (first use in this function)

[mark@thelinux src]# gcc -v
gcc version 4.0.2 20051125 (Red Hat 4.0.2-8)
I'm guessing the same applies to vc.

Nice try, but some of us have VC and don't have to guess and get the
facts right.
I have VC, and I can get the facts right too.

Compiling...
clc_test.c
clc_test.c(4) : error C2065: 'try' : undeclared identifier
clc_test.c(7) : warning C4013: 'catch' undefined; assuming extern
returning int
Error executing cl.exe.

clc_test.obj - 2 error(s), 1 warning(s)

--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan
Jul 11 '06 #32

P: n/a
"Ancient_Hacker" <gr**@comcast.netwrote:
Richard Heathfield wrote:
Not only did the OP not specify Unix, but this is not guaranteed to work
even on that platform. For example, the library might allocate page-sized
blocks. If so, allocating a three-byte block would result in p + 3 being
invalid in C language terms but acceptable to the OS (but
comp.unix.programmer would know more about that). I just tested this by
allocating three bytes and writing to all four of them (admittedly on Linux
rather than Unix), and the write did not cause a segfault.

We don't know exactly what the OP meant by "valid", but let me guess
Usually when people ask about accessing A+3, they intend to use 32-bit
instructions to manipulate 8-bit data, sometimes with pre-fetch at the
end . A very common case is CRC-ing a network packet, which can be
done very speedily if you allow a little slop. Same with some
pattern-matching operations.

Which means the last time thru the loop the code might pre-fetch up to
3 bytes past the end of data. So all they might want to know is if the
memory is readable without major kabooms.

There isnt a way I know of in the C language to do this,
Of course there is a way in ISO C to do this. Just don't muck about with
possibly-invalid pointers and #ifdef LINUX-kernel-4.2 and Microsoftian
blunders like that, but simply make sure that you always allocate enough
memory for what you want to do in the first place. In the above case,
make sure the value you pass to malloc() is the smallest multiple of
four greater than or equal to the size of your data. How to determine
that value is left as an easy exercise for the reader.
(2) On most systems that have exception handling try/catch, you can
usually catch address exceptions.
C doesn't have try/catch.

Well, disingenous at best. The two most common C compilers, gcc and vc
which together cover maybe 80% of the market, DO have try and catch.
But not compatibly, TTBOMK, and not in C mode but in C++ mode, which
forces you to debilitate your code in other ways.
(3) On Windows, and I suspect Unix/Linux, you can ask the OS for a list
of memory segments allocated to your process, and their attributes.
Search the list to see if the desired address lands inside a readble
or writeable area.
How are you going to do that in a portable manner, though? The OP posted in
comp.lang.c, which suggests he wants an answer in C language terms, not a
system call which will vary from system to system.

Well, for gnu and vc IIRC
And how were you going to do that in a _portable_ manner?
Yep, it's a non-portable technique. Moving the code to a new system
might take, oh, two hours to rename a few API calls.
_If_ those API calls are available on the new platform.
Versus stewing (as I have) for months trying to find unset pointers.
That just proves that the right way to go about this is to write code
that doesn't care in the first place. Do your bookkeeping properly; then
you won't _have_ to find unset pointers.
Programming involves a lot of analog value judgements. Is it better to
catch 3/4 of the problems, or just claim it's impossible?
It's better to write code that doesn't have the problem.
Is it okay to save a plane crashing by using a feature that has been
in 92% of the C compilers out there for a handful of years, even though
it's not in any standard, or do we just buy a flower-farm to send to
funerals?
It's better not to write code that needs the feature, especially when
lives depend on it.
Things arent always black and white. Many times a little openness to
shades of gray can be very helpful.
Thinking before you code, rather than halfway through when you notice
that you've made some unwarranted assumptions, is more helpful.

Richard
Jul 12 '06 #33

P: n/a

In article <ha************@news.flash-gordon.me.uk>, Flash Gordon <sp**@flash-gordon.me.ukwrites:
>
Actually, MS VC++ implements _try as an extension to C.
More specifically (and OT, of course, but for the sake of clarity),
if extensions are enabled, MS VC recognizes the additional keywords
__try, __except, __finally, __leave, and GetExceptionCode (which
looks like a function but is actually a keyword).[1]

These keywords can be used to instruct the compiler to generate code
for Windows Structured Exception Handling, which is not a language
feature, but an OS one. It is completely separate from the C++
exception mechanism, for example, and conflating the two as
"Ancient_Hacker" did is deceptive.
1. Depending on headers included, etc, variations of these may be
defined as object-style macros, so "_try" and "try" may be defined
as aliases for "__try". As of VC6, however, the double-underscore
forms are the official ones.

--
Michael Wojcik mi************@microfocus.com

Vinegar keeps more flies away than honey does.
Jul 12 '06 #34

This discussion thread is closed

Replies have been disabled for this discussion.