comp.lang.c - 25 new messages in 6 topics - digest
comp.lang.c
http://groups.google.com/group/comp.lang.c?hl=en
Today's topics:
* 16:32 far pointers in OpenWatcom C/C++ - 9 messages, 5 authors
http://groups.google.com/group/comp.lang.c/t/4728dadef590aafe?hl=en
* Container library (continued) - 4 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/3763649cc890efcc?hl=en
* Weird problem with pointer dereferencing - 4 messages, 4 authors
http://groups.google.com/group/comp.lang.c/t/5b6e9639b0aea73e?hl=en
* How should I test for a null pointer? - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/ac6fdf22358cde1a?hl=en
* Changing from && to || - 4 messages, 3 authors
http://groups.google.com/group/comp.lang.c/t/412979e4b3c7cf45?hl=en
* Question about pointer conversion - 3 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/3a16b9b33cb0cdd0?hl=en
==============================================================================
TOPIC: 16:32 far pointers in OpenWatcom C/C++
http://groups.google.com/group/comp.lang.c/t/4728dadef590aafe?hl=en
==============================================================================
== 1 of 9 ==
Date: Thurs, Mar 25 2010 3:18 am
From: Branimir Maksimovic
On Thu, 25 Mar 2010 07:45:40 +0000
Ahem A Rivet's Shot <steveo@eircom.net> wrote:
> On Wed, 24 Mar 2010 11:49:16 -0700
> Keith Thompson <kst-u@mib.org> wrote:
>
> > Ahem A Rivet's Shot <steveo@eircom.net> writes:
> > > On Wed, 24 Mar 2010 15:57:46 +0100
> > > Branimir Maksimovic <bmaxa@hotmail.com> wrote:
> > [...]
> > >> Remember size_t is typedef. Can;t be float, can;t be pointer,
> > >> it has to be one of available ints.
> > >
> > > It doesn't have to be a typedef - it usually is but it
> > > doesn't have to be.
> >
> > How could size_t not be a typedef? It's not a keyword or a macro.
>
> It can be a type.
>
Is there any significant difference of C size_t and C++ size_t.
I know in C++, you have to include at least cstddef or stddef.h.
Always thought that size_t is just typedef for largest unsigned int.
Greets!
Sometimes online sometimes not
== 2 of 9 ==
Date: Thurs, Mar 25 2010 4:00 am
From: Peter Flass
Nick Keighley wrote:
> On 25 Mar, 00:56, Keith Thompson <ks...@mib.org> wrote:
>> Seebs <usenet-nos...@seebs.net> writes:
>>> On 2010-03-24, Keith Thompson <ks...@mib.org> wrote:
>>>> Ahem A Rivet's Shot <ste...@eircom.net> writes:
>
>>>>> It doesn't have to be a typedef - it usually is but it doesn't have
>>>>> to be.
>>>> How could size_t not be a typedef? It's not a keyword or a macro.
>>> It could, however, be treated magically by the compiler.
>
> consider a Maximally Perverse Compiler...
>
>
>>> Which means that, while it appears to necessarily have the same semantics
>>> as a typedef, there's no requirement that it actually *is* one.
>
> actually the Standard says "The following types [...] are defined
> [...] size_t". I thought a typedef didn't create a type but merely a
> type alias. Doesn't this mean typedef has the wrong semantics to
> define size_t and hence size_t /cannot/ be a typedef?
>
> Ok, from the standard:- "A typedef declaration does not introduce a
> new type, only a synonym for the type so specified."
>
>> How is something with the same semantics as a typedef not a typedef?
>>
>> Yeah, ok, there might not be a line of C source code containing the
>> tokens "typedef" and "size_t" in whatever entity "#include <stddef.h>"
>> refers to. Similarly, printf might be some magic thing that acts like
>> a variadic function, but really isn't one.
>
> I'd invoke the "As If" rule. I agree with your duck remark below.
>
>> To put it another way, a typedef declaration, perhaps
>> typedef unsigned long size_t;
>> that appears when you write
>> #include <stddef.h>
>> perfectly satisifies the standard's requirements for size_t. And no
>> other C construct does so.
>>
>> It quacks like a duck.
>
>
> I bet afc thought they had all the crazy people to themselves...
>
>
Not any more;-) How many typedefs can dance on the head of a pin?
== 3 of 9 ==
Date: Thurs, Mar 25 2010 4:16 am
From: Sol-Terrasa mkfs ext4 da' Sussex
On Thu, 2010-03-25 at 11:16 +0100, Branimir Maksimovic wrote:
> bmaxa@maxa:~/armjpeg/asmtest$ gcc main.c -o main
> bmaxa@maxa:~/armjpeg/asmtest$ ./main
> bytes 512
> 0x602040 0x602000
> 3
> 5
Causes a segmentation fault on x86 :-D
--
http://www.munted.org.uk
One very high maintenance cat living here.
== 4 of 9 ==
Date: Thurs, Mar 25 2010 4:18 am
From: Nick Keighley
On 25 Mar, 10:16, Branimir Maksimovic <bm...@hotmail.com> wrote:
> On Thu, 25 Mar 2010 02:57:06 -0700 (PDT)
> Nick Keighley <nick_keighley_nos...@hotmail.com> wrote:
> > On 24 Mar, 22:03, Branimir Maksimovic <bm...@hotmail.com> wrote:
> > > On Wed, 24 Mar 2010 14:04:54 -0700
> > > Keith Thompson <ks...@mib.org> wrote:
<snip>
> > > I first learned basic than assembler on spectrum 48kb.
> > > Then somehow C compiler was available for spectrum,
> > > so when I saw ++ operator, immediately recognized
> > > C as another assembler.
>
> > and you were mistaken. Assembler maps one-to-one (yes I know about
> > macro-assemblers) to machine code. C doesn't really do that.
the other important thing about assemblers is that they are tied to a
particular machine. Well written C can run on different machines.
<snip>
> > > Especially was fascinated that
> > > you could crash computer with it same as in assembler.
>
> > this makes Windows NT an assembler
>
> Windows NT is OS.
if you can crash a computer with it it's an assembler
you can crash a computer with Windows NT
=> Windows NT is an assembler
> > > Technically pointers are integers,
>
> > no.
>
> Numbers.
no.
> Ok , I think you all mean by integer mathematical
> integer. My meaning for integer is digit, number.
pointers aren't numbers. Not integers, sureals nor octonions.
> > > Yes but, when you malloc you get chunk of raw memory
> > > that can be indexed by integers of any type.
> > > This maps 1-1 on assembler thinkology ;)
>
> > so Fortran and Java are assembler?
>
> Nope. I programed fortran iV , different thinking
> not like assembler. Java also requires different
> thinking.
we'll just have to agree to disagree
== 5 of 9 ==
Date: Thurs, Mar 25 2010 4:18 am
From: Branimir Maksimovic
On Thu, 25 Mar 2010 11:16:11 +0000
Sol-Terrasa mkfs ext4 da' Sussex <alex.buell@munted.org.uk> wrote:
> On Thu, 2010-03-25 at 11:16 +0100, Branimir Maksimovic wrote:
> > bmaxa@maxa:~/armjpeg/asmtest$ gcc main.c -o main
> > bmaxa@maxa:~/armjpeg/asmtest$ ./main
> > bytes 512
> > 0x602040 0x602000
> > 3
> > 5
>
> Causes a segmentation fault on x86 :-D
Of course , you have to as -R first object file ;)
Greets
Sometimes online sometimes not
== 6 of 9 ==
Date: Thurs, Mar 25 2010 4:41 am
From: Ben Bacarisse
Phil Carmody <thefatphil_demunged@yahoo.co.uk> writes:
> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>> Phil Carmody <thefatphil_demunged@yahoo.co.uk> writes:
>>> Seebs <usenet-nospam@seebs.net> writes:
>>>> On 2010-03-24, Keith Thompson <kst-u@mib.org> wrote:
>>>>> Ahem A Rivet's Shot <steveo@eircom.net> writes:
>>>>>> It doesn't have to be a typedef - it usually is but it doesn't have
>>>>>> to be.
>>>>
>>>>> How could size_t not be a typedef? It's not a keyword or a macro.
>>>>
>>>> It could, however, be treated magically by the compiler.
>>>>
>>>> Which means that, while it appears to necessarily have the same semantics
>>>> as a typedef, there's no requirement that it actually *is* one.
>>>
>>> It has to be a 'type' which has a 'corresponding signed type',
>>
>> I can't find this requirement. Where does it come from?
>
> Ref posted elsethread, but it was the description of printf's %z.
That allows for the possibility. You say its existence is required.
That's the bit I can't find.
>> (The reverse: that for every signed integer type there is a
>> corresponding unsigned integer type is certainly true).
>>
>>> and it
>>> has to be both 'declared' and 'defined'. Not many things can be all
>>> of those.
>>
>> All sorts of magic might be involved:
>>
>> __declare__and__define('size_t', '48 bits');
>
> There's no C declaration there, and no C definition there. The
> terms are clearly defined by the C standard, and even have
> grammatical rules specifying them, and the above is neither.
>
>> or maybe the type just pops into existence when one of the appropriate
>> header files is seen, but in most cases there is no reason not to use
>> a typedef.
>
> If it were to just pop into existence, then there would be
> no declaration/definition of it. The standard insists there
> is a declaration/definition.
The standard permits extensions and I take that to include extensions
to the ways types are defined and declared. Obviously you don't.
Does it matter?
--
Ben.
== 7 of 9 ==
Date: Thurs, Mar 25 2010 4:52 am
From: Ben Bacarisse
Nick Keighley <nick_keighley_nospam@hotmail.com> writes:
> On 25 Mar, 00:56, Keith Thompson <ks...@mib.org> wrote:
>> Seebs <usenet-nos...@seebs.net> writes:
>> > On 2010-03-24, Keith Thompson <ks...@mib.org> wrote:
>> >> Ahem A Rivet's Shot <ste...@eircom.net> writes:
>
>> >>> It doesn't have to be a typedef - it usually is but it doesn't have
>> >>> to be.
>>
>> >> How could size_t not be a typedef? It's not a keyword or a macro.
>>
>> > It could, however, be treated magically by the compiler.
>
> consider a Maximally Perverse Compiler...
>
>
>> > Which means that, while it appears to necessarily have the same semantics
>> > as a typedef, there's no requirement that it actually *is* one.
>
> actually the Standard says "The following types [...] are defined
> [...] size_t". I thought a typedef didn't create a type but merely a
> type alias. Doesn't this mean typedef has the wrong semantics to
> define size_t and hence size_t /cannot/ be a typedef?
>
> Ok, from the standard:- "A typedef declaration does not introduce a
> new type, only a synonym for the type so specified."
size_t does not have to be a "new type" (at least I can't see any such
requirement) but you are right that it does have to be defined. The
section on typedef (6.7.7) is titled "Type definitions" so I pretty
sure that the committee wants us to think of a typdedef as defining a
type, albeit in the very limited sense of defining an alias.
<snip>
--
Ben.
== 8 of 9 ==
Date: Thurs, Mar 25 2010 5:06 am
From: Ben Bacarisse
Branimir Maksimovic <bmaxa@hotmail.com> writes:
<snip>
> bmaxa@maxa:~$ gcc -std=c89 ts.c -o ts
> ts.c: In function 'main':
> ts.c:5: warning: initialization from incompatible pointer type
> ts.c:6: warning: initialization makes pointer from integer without a cast
> bmaxa@maxa:~$
> bmaxa@maxa:~$ cat ts.c
> int main(void)
> {
> int a=10;
> int *pa = &a;
> float *p = pa;
> float *p1 = 0xdeadbeef;
>
> return 0;
> }
> bmaxa@maxa:~$
>
> That is why C is better than C++. You don;t have to cast in order
> to compile such code. But with C you get *warnings* when you
> do such things, unlike in C++ (more verbose code, but dangerous code
> without warnings)
That's not a difference between the languages. What you mean is you
prefer the choices made by gcc's C compiler to those of its C++
compiler. In both languages, a "diagnostic message" is required,
after which the implementation may do whatever it likes. The above is
as much an error in C++ as it is in C.
<snip>
--
Ben.
== 9 of 9 ==
Date: Thurs, Mar 25 2010 5:29 am
From: Branimir Maksimovic
On Thu, 25 Mar 2010 12:06:30 +0000
Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
> Branimir Maksimovic <bmaxa@hotmail.com> writes:
> <snip>
> > bmaxa@maxa:~$ gcc -std=c89 ts.c -o ts
> > ts.c: In function 'main':
> > ts.c:5: warning: initialization from incompatible pointer type
> > ts.c:6: warning: initialization makes pointer from integer without
> > a cast bmaxa@maxa:~$
> > bmaxa@maxa:~$ cat ts.c
> > int main(void)
> > {
> > int a=10;
> > int *pa = &a;
> > float *p = pa;
> > float *p1 = 0xdeadbeef;
> >
> > return 0;
> > }
> > bmaxa@maxa:~$
> >
> > That is why C is better than C++. You don;t have to cast in order
> > to compile such code. But with C you get *warnings* when you
> > do such things, unlike in C++ (more verbose code, but dangerous code
> > without warnings)
>
> That's not a difference between the languages. What you mean is you
> prefer the choices made by gcc's C compiler to those of its C++
> compiler. In both languages, a "diagnostic message" is required,
> after which the implementation may do whatever it likes. The above is
> as much an error in C++ as it is in C.
Hm, that is bug in standard I think and should be corrected.
I think that following is more buggy and I don't get warning.
Pretty annoying when you don;t have a warning and have to maintain
or port code.
bmaxa@maxa:~$ gcc ts.c -o ts
bmaxa@maxa:~$ cat ts.c
#include <stddef.h>
int main(void)
{
size_t a=10;
int *pa = (int*)a;
void *p = pa;
float* pf = p;
return 0;
}
bmaxa@maxa:~$
bmaxa@maxa:~$ gcc -Wall -Wextra -std=c99 ts.c -o ts
ts.c: In function 'main':
ts.c:8: warning: unused variable 'pf'
bmaxa@maxa:~$
See, what standard did? Legalize buggy code?
Greets!
Sometimes online sometimes not
==============================================================================
TOPIC: Container library (continued)
http://groups.google.com/group/comp.lang.c/t/3763649cc890efcc?hl=en
==============================================================================
== 1 of 4 ==
Date: Thurs, Mar 25 2010 3:26 am
From: Nick Keighley
On 20 Mar, 02:48, "ng2010" <ng2...@att.invalid> wrote:
> "Seebs" <usenet-nos...@seebs.net> wrote in message
>
> news:slrnhq223i.oe0.usenet-nospam@guild.seebs.net...
>
>
>
> > I have often used list libraries. I'd use hash libraries if I needed a
> > hash.
> > In neither case would I use a "container" library in C -- it's the
> > wrong
> > level of abstraction for C, so far as I can tell. I've never in any
> > language
> > wanted "a container". In OO languages, it's useful that the specific
> > things
> > I request are also generically "containers". In C, it's not useful,
> > because
> > I can't do anything with it.
>
> This sounds sooo much like thrashing on whether a "Line" should draw
> itself or should be drawn by a "Canvas" or other abstraction. Don't walk,
> run to the next level: jettison old paradigms.
so what's the answer?
== 2 of 4 ==
Date: Thurs, Mar 25 2010 3:30 am
From: Nick Keighley
On 25 Mar, 05:24, Tim Rentsch <t...@x-alumni2.alumni.caltech.edu>
wrote:
> Seebs <usenet-nos...@seebs.net> writes:
> > On 2010-03-20, ng2010 <ng2...@att.invalid> wrote:
> >> This sounds sooo much like thrashing on whether a "Line" should draw
> >> itself or should be drawn by a "Canvas" or other abstraction. Don't walk,
> >> run to the next level: jettison old paradigms.
>
> > This is pretty useless advice.
>
> > Understanding what makes a design work is important regardless of language.
>
> This comment seems somewhat naive. Some design patterns work much
> better in one programming paradigm than another, and different
> languages are definitely different in how well they fit different
> paradigms. For example, C is just fine for procedural programming,
> maybe okay for object-oriented programming, somewhere between fair
> and poor (depending on "how functional") for functional programming,
> and generally awful for logic programming. If someone is content to
> stick just with design patterns that work in procedural programming
> or (not too emphatic) object-oriented programming, then these all can
> be expressed in C (or most other widely used procedural languages).
> If, however, one wants to use functional programming design patterns
> or logic programming design patterns, then trying to express said
> designs in C will be fraught with difficulties. Of course, in the
> literal sense the last statement quoted above may be true --
> understanding what makes a design work _is_ important no matter which
> language will be used to implement the design. But choosing a good
> design, as well as understanding what makes it work, is _not_
> independent of language, because not all designs work in all
> languages.
http://www.paulgraham.com/avg.html
== 3 of 4 ==
Date: Thurs, Mar 25 2010 3:32 am
From: Nick Keighley
On 25 Mar, 05:35, Seebs <usenet-nos...@seebs.net> wrote:
> On 2010-03-25, Tim Rentsch <t...@x-alumni2.alumni.caltech.edu> wrote:
>
> > Seebs <usenet-nos...@seebs.net> writes:
> >> Understanding what makes a design work is important regardless of language.
> > This comment seems somewhat naive. Some design patterns work much
> > better in one programming paradigm than another, and different
> > languages are definitely different in how well they fit different
> > paradigms.
>
> Sure.
>
> > If, however, one wants to use functional programming design patterns
> > or logic programming design patterns, then trying to express said
> > designs in C will be fraught with difficulties.
>
> Yes. That doesn't make it useless to look at how they work effectively,
> even if the conclusion that leads you to is "this is a poor fit for
> this language". :)
>
> > Of course, in the
> > literal sense the last statement quoted above may be true --
> > understanding what makes a design work _is_ important no matter which
> > language will be used to implement the design. But choosing a good
> > design, as well as understanding what makes it work, is _not_
> > independent of language, because not all designs work in all
> > languages.
>
> Agreed. But in a case like this in particular, I think it's quite
> reasonable to talk about the kinds of design Jacob is looking at in
> terms of C. There are good reasons to implement these things in C
> at one level or another, and good reasons not to jump to C++.
>
> Newness for the sake of newness is not a particularly good engineering
> strategy.
replicating wooden bridge design in iron isn't good either
== 4 of 4 ==
Date: Thurs, Mar 25 2010 3:46 am
From: Nick Keighley
On 24 Mar, 04:57, "ng2010" <ng2...@att.invalid> wrote:
> "jacob navia" <ja...@nospam.org> wrote in message
> news:ho1u16$cl5$1@speranza.aioe.org...
> > ng2010 a crit :
> >> "jacob navia" <ja...@spamsink.net> wrote in message
> >>news:hnr08l$1ev$1@speranza.aioe.org...
> >>> Seebs a crit :
> >>>> On 2010-03-17, jacob navia <ja...@nospam.org> wrote:
ng:
If you hate C so much why do you post here?
> >> iron of detroit will be gone, rusted away. So
> >> will C rust away.
I wouldn't hold your beath though. Most of the modern clever stuff
sits on top of a C implementation layer.
> > The usage of C is not decreasing but increasing. Big and important
> > projects like the linux kernel, Apache, and many others are written
> > in C.
>
> Don't yell/advertise that too loudly, because that will increasingly
> become a negative trait and a characteristic of obsolescence. All you did
> was state large and incomprehensible codebases and poorly designed
> software. (The Apache folks have some useful libraries that would be
> better if not for the limitations of the language they are written in).
>
> (Aside: Go Apache! Linux go suck a rock. GPL sucks!)
what platform are you reading this on? I bet there's a fair amount of
C in there
> > The folks in C++ have been yelling this for ages now and
> > the usage of C doesn't disminish at all.
>
> C++ owes much of it's non-lucrativity to C. (Maybe ALL of it).
template syntax...
<snip>
> >> "A few" still drive around the old cars, but they are still deathtraps
> >> and old, obsolete technology.
>
> > Because you believe that more complexity is better. Go on. I believe
> > that the future belongs to SIMPLER languages.
"Programming languages should be designed not by piling feature on top
of feature, but by removing the weaknesses and restrictions that make
additional features appear necessary."
> You're not listening. (Did I mention something about "burying your head
> in the sand"?). I don't know you, so I don't know your ability to
> comprehend, learn and think. But you dialog in this thread so far to me
> seems to be very self-centered at worst, or childish at best.
you seem to think anyone who doesn't agree with you is stupid
<snip>
> > You, and all those
> > C++ zealots try to destroy C because deep in their minds they are
> > afraid
> > that people realize that what is important in a language is simplicity
> > and power, not complexity.
ah, back to the dark, paranoid side
> As if you knew something about language design.
you do?
--
"If you think C++ is not overly complicated, just what is a protected
abstract virtual base pure virtual private destructor, and when
was the last time you needed one?"
-- Tom Cargil, C++ Journal.
==============================================================================
TOPIC: Weird problem with pointer dereferencing
http://groups.google.com/group/comp.lang.c/t/5b6e9639b0aea73e?hl=en
==============================================================================
== 1 of 4 ==
Date: Thurs, Mar 25 2010 3:55 am
From: Branimir Maksimovic
On Thu, 25 Mar 2010 10:03:24 +0000
Rui Maciel <rui.maciel@gmail.com> wrote:
> Consider the following test program:
>
....
>
> So, is this supposed to happen? I was expecting that the pointer
> dereference would only change the value stored in the memory address
> pointed to by b->limit. Why is that memory dereferencing screwing up
> with b->p?
Because probably there is where b->limit points to?
Greets!
Sometimes online sometimes not
== 2 of 4 ==
Date: Thurs, Mar 25 2010 3:56 am
From: pacman@kosh.dhis.org (Alan Curry)
In article <4bab34ef$0$361$a729d347@news.telepac.pt>,
Rui Maciel <rui.maciel@gmail.com> wrote:
|struct buffer
|{
| #define BUFFER_SIZE 16
| char buffer[BUFFER_SIZE];
| char *p; /* cursor */
| char *q; /* YYMARKER */
| char *marker; /* token start marker */
| char *limit; /* limit marker */
|};
[...]
|(gdb) n
|26 *b->limit = '\0'; // <----- offending line
|(gdb) print *b
|$1 = {buffer = "asdf asdf asdf a", p = 0x7fffffffdce0 "asdf asdf asdf
|a\340\334\377\377\377\177", q = 0x7fffffffdcf0 "\340\334\377\377\377\177",
| marker = 0x7fffffffdce0 "asdf asdf asdf a\340\334\377\377\377\177", limit =
|0x7fffffffdcf0 "\340\334\377\377\377\177"}
|(gdb) n
|28 }
|(gdb) print *b
|$2 = {buffer = "asdf asdf asdf a", p = 0x7fffffffdc00 "\021 d\r", q =
|0x7fffffffdcf0 "",
|marker = 0x7fffffffdce0 "asdf asdf asdf a", limit = 0x7fffffffdcf0 ""}
|</gdb output>
Your struct is located at 0x7fffffffdce0. The first field, buffer, is also
located at 0x7fffffffdce0. Its size is 16. Your b->limit pointer is
0x7fffffffdcf0, also known as 0x7fffffffdce0+16 or &buffer[16]. It's outside
the bounds of the array. Dereferencing b->limit is a classic buffer overflow
error, and writing to it caused memory corruption elsewhere.
The "elsewhere" happened to be b->p because the p field immediately follows
the buffer, and there was no padding between them.
--
Alan Curry
== 3 of 4 ==
Date: Thurs, Mar 25 2010 4:06 am
From: ike@localhost.claranet.nl (Ike Naar)
In article <4bab34ef$0$361$a729d347@news.telepac.pt>,
Rui Maciel <rui.maciel@gmail.com> wrote:
>#include <string.h>
>#include <stdio.h>
>
>struct buffer
>{
> #define BUFFER_SIZE 16
> char buffer[BUFFER_SIZE];
> char *p; /* cursor */
> char *q; /* YYMARKER */
> char *marker; /* token start marker */
> char *limit; /* limit marker */
>};
>
>void fill(FILE *file, struct buffer *b)
>{
> if(feof(file))
> {
> }
> else if(b->p > b->limit - 10)
> {
> memmove(b->buffer,b->marker, b->limit - b->marker);
> b->limit = b->buffer + (b->limit - b->marker) +
>fread(b->buffer + (b->limit
>- b->marker),sizeof(char),BUFFER_SIZE-(b->limit-b->marker),file);
> b->p = b->buffer + (b->p - b->marker);
> b->marker = b->buffer;
> *b->limit = '\0'; // <----- offending line
> }
>}
>
>
>int main(void)
>{
> struct buffer b = {.p = b.buffer+BUFFER_SIZE, .q=
>b.buffer+BUFFER_SIZE, .marker =
>b.buffer+BUFFER_SIZE, .limit = b.buffer+BUFFER_SIZE};
>
> fill(stdin, &b);
>
> return 0;
>}
></code>
>
>
>I've noticed that the pointer dereferencing done at the marked offending
>line not only sets
>*b->limit to '\0' but also has the nasty side effect of screwing up with
>the address pointed to by b->p.
You are writing outside the buffer; it is only BUFFER_SIZE characters
long, but you're writing a '\0' on top of the (BUFFER_SIZE+1)'st character.
== 4 of 4 ==
Date: Thurs, Mar 25 2010 4:15 am
From: Rui Maciel
Alan Curry wrote:
> Your struct is located at 0x7fffffffdce0. The first field, buffer, is also
> located at 0x7fffffffdce0. Its size is 16. Your b->limit pointer is
> 0x7fffffffdcf0, also known as 0x7fffffffdce0+16 or &buffer[16]. It's
> outside the bounds of the array. Dereferencing b->limit is a classic
> buffer overflow error, and writing to it caused memory corruption
> elsewhere.
>
> The "elsewhere" happened to be b->p because the p field immediately
> follows the buffer, and there was no padding between them.
You are absolutely right. The dreaded "off-by-one" error... Shame on me.
Thanks for the help,
Rui Maciel
==============================================================================
TOPIC: How should I test for a null pointer?
http://groups.google.com/group/comp.lang.c/t/ac6fdf22358cde1a?hl=en
==============================================================================
== 1 of 1 ==
Date: Thurs, Mar 25 2010 4:03 am
From: Nick Keighley
On 24 Mar, 03:40, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
> > # FALSE and NOT FALSE is just nasty
> > if booleanvalue != FALSE # This looks really nasty. I wouldn't do
> > that
>
> You should never need to. 'if booleanvalue' should work in all but
> the clumsiest programming languages.
not all programming languages have booleans. Consider Coral-66
IF finished = TRUE THEN
terminate (link);
(syntax from memory!)
==============================================================================
TOPIC: Changing from && to ||
http://groups.google.com/group/comp.lang.c/t/412979e4b3c7cf45?hl=en
==============================================================================
== 1 of 4 ==
Date: Thurs, Mar 25 2010 4:18 am
From: James Harris
On 24 Mar, 13:58, Dr Malcolm McLean <malcolm.mcle...@btinternet.com>
wrote:
...
> > In full it would be, using your format,
>
> > #define C_CALL(a, b) ((a) < (b) || f((a), (b)))
>
> > > > Have I got the change right?
>
> > > I think so, but it all looks unnecessarily devious
>
> > Is it more devious than other macros? It doesn't use ?: so is easier
> > to read than many.
>
> I'd write it as
>
> (( (a) >= (b) ) ? f( (a), (b) ) : true)
>
> It's not obvious from your macro that the return is important.
I see your point. Given just the info in my query it's not obvious
whether a return value is expected or not. But I can't quite take to
the ?: form if it's not needed.
Maybe we should expect (not mentally elide) a return value.
Speaking for myself
(c) && f()
looks much more familiar than
(c) || f()
and flows better mentally. I guess I tend to read the first as: if c
then *do* f(). The second, using ||, being less familiar is harder to
read. It could be: if not c then do f(). However, it also returns true
if c is true so including "not c" when reading it is misleading.
Perhaps it's better read as: if c then do nothing, otherwise do f().
And then if used in a boolean context: if c return 1, otherwise return
f().
So, using "return" in the non-keyword sense, maybe it's better to read
both conditional expressions as
(c) && f() becomes if c return f(), else return 0
(c) || f() becomes if c return 1, else return f()
I hope that's right. No doubt someone will correct me if not.
James
== 2 of 4 ==
Date: Thurs, Mar 25 2010 5:05 am
From: pete
James Harris wrote:
> On 24 Mar, 13:58, Dr Malcolm McLean <malcolm.mcle...@btinternet.com>
> wrote:
> ...
>>> In full it would be, using your format,
>>> #define C_CALL(a, b) ((a) < (b) || f((a), (b)))
>>>>> Have I got the change right?
>>>> I think so, but it all looks unnecessarily devious
>>> Is it more devious than other macros? It doesn't use ?: so is easier
>>> to read than many.
>> I'd write it as
>>
>> (( (a) >= (b) ) ? f( (a), (b) ) : true)
>>
>> It's not obvious from your macro that the return is important.
>
> I see your point. Given just the info in my query it's not obvious
> whether a return value is expected or not. But I can't quite take to
> the ?: form if it's not needed.
>
> Maybe we should expect (not mentally elide) a return value.
>
> Speaking for myself
>
> (c) && f()
>
> looks much more familiar than
>
> (c) || f()
>
> and flows better mentally. I guess I tend to read the first as: if c
> then *do* f(). The second, using ||, being less familiar is harder to
> read. It could be: if not c then do f(). However, it also returns true
> if c is true so including "not c" when reading it is misleading.
>
> Perhaps it's better read as: if c then do nothing, otherwise do f().
>
> And then if used in a boolean context: if c return 1, otherwise return
> f().
>
> So, using "return" in the non-keyword sense, maybe it's better to read
> both conditional expressions as
>
> (c) && f() becomes if c return f(), else return 0
> (c) || f() becomes if c return 1, else return f()
>
> I hope that's right. No doubt someone will correct me if not.
It isn't right.
The value of ((c) && f()) is either one or zero.
The value of ((c) || f()) is either one or zero.
--
pete
== 3 of 4 ==
Date: Thurs, Mar 25 2010 5:12 am
From: James Harris
On 24 Mar, 15:55, Nick Keighley <nick_keighley_nos...@hotmail.com>
wrote:
...
> > Is it more devious than other macros?
>
> no, its just putting stuff like this in macros is generally devious
>
> It doesn't use ?: so is easier
I do agree. Putting stuff like this in macros is not generally a good
idea. I'll explain why I did in this case. See if it makes it any more
palatable.
It's from my xbuf routines
http://codewiki.wikispaces.com/xbuf.c
They include a called routine which, if necessary, increases the size
of a buffer. It carries out the following test
if (buffer is not big enough) {expand the buffer}
If used naively the buffer would be big enough most of the time and so
the called routine would return having done nothing except wasted
time. I wanted to make the routine suitable for use in tight loops.
How? The idea is that the calling code carries out the *same test*
before calling the routine so we get in the user's code
if (buffer is not big enough) {call the routine}
Depending on architecture and compiler this should compile to
something like two instructions: a simple test and a branch. With
modern branch prediction the cost of these two instructions would
virtually disappear and would be much faster than only carrying out
the test in a subroutine call.
I could expect the user of the routine to include the code for the
test but that commits some sins, in increasing order of sinfulness...
1) bulks up the caller's code,
2) diverts attention away from the normal flow and the user's
application logic and,
3) exposes some of the internals of the called routine to the
programmer using the routine.
Using a macro avoids these issues. Of course, being in all capitals
the macro name serves as the usual warning about parameter evaluation.
So, I think the macro is pragmatic and the right thing to do in this
case. YMMV. The better solution, IMHO, would be if we could depend on
optimisation between procedures - but that's another topic.
James
== 4 of 4 ==
Date: Thurs, Mar 25 2010 5:16 am
From: Ben Bacarisse
James Harris <james.harris.1@googlemail.com> writes:
<snip>
> So, using "return" in the non-keyword sense, maybe it's better to read
> both conditional expressions as
>
> (c) && f() becomes if c return f(), else return 0
> (c) || f() becomes if c return 1, else return f()
>
> I hope that's right. No doubt someone will correct me if not.
In your specific case, yes, but only because f() returns 0 or 1. I'd
choose between c && f() and c ? f() : 0 depending on what I wanted the
reader to focus on -- the Boolean nature of the expression or the
return value of f().
--
Ben.
==============================================================================
TOPIC: Question about pointer conversion
http://groups.google.com/group/comp.lang.c/t/3a16b9b33cb0cdd0?hl=en
==============================================================================
== 1 of 3 ==
Date: Thurs, Mar 25 2010 4:43 am
From: Luca Forlizzi
On 24 Mar, 00:09, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
> (1) I would not loose a moment's sleep over it. :-)
agreed :-)
>
> (2) Yes, one can probably deduce this from the standard. I'd start
> with 6.2.5 ("Types") p27:
>
> "A pointer to void shall have the same representation and alignment
> requirements as a pointer to a character type. [...]"
>
> to which is attached a footnote (all together now: "non-normative"):
>
> "The same representation and alignment requirements are meant to
> imply interchangeability as arguments to functions, return values
> from functions, and members of unions."
so this basically mean that converting a pointer p to void* gives a
pointer to the first byte,
just as converting p to unsigned char*, isn't it?
thanks for answering my silly questions!
Luca
== 2 of 3 ==
Date: Thurs, Mar 25 2010 4:51 am
From: Luca Forlizzi
On 23 Mar, 23:10, Barry Schwarz <schwa...@dqel.com> wrote:
> On Tue, 23 Mar 2010 14:14:03 -0700 (PDT), Luca Forlizzi
> I assume you meant int* here since converting it to an int will cause
> it not to point anywhere.
yes, excuse me
>
> >a pointer to the first of the ints
> >inside X[0] ? I was only able to find that 6.3.2.3 p7 says that
>
> You neglected to tell us what X was since you changed threads but if
> it was an N dimensional array of int, then yes.
yes again
> >converting to a character type we have
> >a pointer to the first byte.
> >Please note that in the case of the implicit array-to-pointer
> >conversion this is stated explicitely, and
> >so is the analogous statement for structs and unions.
>
> What implicit conversion are you referring to?
the convertion described in 6.3.2.1 p.3
> >The fact that it's not explicit makes me suspect that this is not
> >guaranteed.
>
> What is not explicit?
the fact that converting a pointer to an array to the type of an array
element, gives a pointer to the initial element
> We won't know till you fill in the holes.
excuse me for being sloppy.
Anyway, Ben's answer has satisfied my curiosity!
Luca
== 3 of 3 ==
Date: Thurs, Mar 25 2010 5:18 am
From: Luca Forlizzi
On 25 Mar, 04:44, Tim Rentsch <t...@x-alumni2.alumni.caltech.edu>
wrote:
> Luca,
> I hope my comments have also helped at least in
> explaining why the issue is so murky and why
> despite that there is still a pretty strong
> consensus about what the Standard "intends" as
> requirements for array-reshaping conversions.
yes they have.
I find your conclusions reasonble and covincing.
I will adopt as rule the comminity consensus, unless an official
statement
would adress the issue.
Thanks a lot to all of you for your help
==============================================================================
You received this message because you are subscribed to the Google Groups "comp.lang.c"
group.
To post to this group, visit http://groups.google.com/group/comp.lang.c?hl=en
To unsubscribe from this group, send email to comp.lang.c+unsubscribe@googlegroups.com
To change the way you get mail from this group, visit:
http://groups.google.com/group/comp.lang.c/subscribe?hl=en
To report abuse, send email explaining the problem to abuse@googlegroups.com
==============================================================================
Google Groups: http://groups.google.com/?hl=en
posted by twitter @ 5:31 AM
0 Comments
0 Comments:
Post a Comment
Subscribe to Post Comments [Atom]
<< Home