Re: why the usage of gets() is dangerous.

Tor Rustad <tor_rustad@xxxxxxxxxxx> wrote:

Richard Bos wrote:
Tor Rustad <tor_rustad@xxxxxxxxxxx> wrote:

His solution requires the use of "fat pointers", which are not
Methinks, fat pointers break pointer arithmetic and thus require at
least a new language dialect.

No, they don't.

Hmm... what about volatile, extern and variable-length arrays?

Why should they be different?

Also, I expect GC's, to do low-level pointer magic.

But GC in itself breaks ISO C compatibility. GC introduces a new
dialect; fat pointers do not.

Pointer arithmetic beyond the bounds of an object has
undefined behaviour anyway,

Off-by-one is allowed, see e.g. response to DR #76 and DR #221.

Of course, but that still doesn't break fat pointers.

and within an object it works fine with fat
pointers. Adding an integer to a pointer is now a matter of adding it to
a single field of the pointer structure, rather than to a flat index,
but something similar is needed with, e.g., segmented architectures.

Well, it appears to me that that segmented architectures capable of C99,
might not be able to have 65535 bytes for an object, when using fat
pointers.

Why on earth not? For starters, who says that segments _must_ be 1980s
Intel 8088-compatible segments?

Also, the buffer passed to gets() may not be malloc'ed, but can be an
array, or even a sub-array.

So? A sub-array simply has it recorded, in its fat pointer data, that it
is a sub-array, and what of.

So... the compiler would generate instrumented code then, lots of
run-time checks!

Yes. That's most the point of fat pointers. They are generally used in
debugging implementations. I don't know of any normal C implementation
which uses them.

This is getting far to theoretical.. fat pointers make sense to me, *if*
C had such a new pointer type, else everyone need to use "the same"
compiler, or how do you suggest we link in libraries in practice?

You misunderstand. Fat pointers are not a new pointer type within ISO C.
Rather, they are a way to implement normal C pointers behind the scene.
And yes, you do need to link fat-pointer-compiled object files with
fat-pointer-compiled libraries; much as you need to link 64-bit object
files with 64-bit libraries, little-endian object files with little-
endian libraries, and on MS-DOS used to link large memory model object
files with large memory model libraries.

Richard
.

Relevant Pages

  • Re: API design problem - buffer scatter I/O
    ... (like thin and fat pointers), but that should come at the end. ... FIRST learn about the semantics of access types, ... "Thin pointers grant access to constrained subtypes." ...
    (comp.lang.ada)
  • Re: why the usage of gets() is dangerous.
    ... That's most the point of fat pointers. ... object files with fat-pointer-compiled libraries; ... array, and entirely usable within its scope. ...
    (comp.lang.c)
  • Re: why cant functions return arrays
    ... size the programmer wrote]. ... fact, "impossible", and there are a few compilers that do ... Implementations that provide fat pointers generally run compiled ...
    (comp.lang.c)
  • Re: why the usage of gets() is dangerous.
    ... That's most the point of fat pointers. ... object files with fat-pointer-compiled libraries; ... link large memory model object files with large memory model ...
    (comp.lang.c)
  • Re: why the usage of gets() is dangerous.
    ... That's most the point of fat pointers. ... link large memory model object files with large memory model ... The implementation does not have to worry about what happens if you (the programmer) do something the C standard states is undefined, since as you know under those situations anything the implementation does is "correct". ...
    (comp.lang.c)