twitter: comp.lang.c - 25 new messages in 7 topics

comp.lang.c
http://groups.google.com/group/comp.lang.c?hl=en

comp.lang.c@googlegroups.com

Today's topics:

* Motivation of software professionals - 11 messages, 9 authors
http://groups.google.com/group/comp.lang.c/t/21a3fdec4dd53e6a?hl=en
* So I want to exhaust a lot of memory - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c/t/efd5686c57529f9b?hl=en
* void * arithmetic - 5 messages, 5 authors
http://groups.google.com/group/comp.lang.c/t/a33b3b6b3dba34c8?hl=en
* pointers - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c/t/8e78c8f2011f3891?hl=en
* Warning to newbies - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/9597fd702985dff4?hl=en
* The C FAQ - 3 messages, 2 authors
http://groups.google.com/group/comp.lang.c/t/b75c0ae09abf3345?hl=en
* representation of register's fields - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/ae3b5f4e576cfbd1?hl=en

==============================================================================
TOPIC: Motivation of software professionals
http://groups.google.com/group/comp.lang.c/t/21a3fdec4dd53e6a?hl=en
==============================================================================

== 1 of 11 ==
Date: Thurs, Feb 11 2010 12:25 pm
From: James Kanze

On Feb 11, 10:05 am, Phil Carmody <thefatphil_demun...@yahoo.co.uk>
wrote:
> James Kanze <james.ka...@gmail.com> writes:

[...]
> >> Nobody knows how to build earthquake-immune buildings, yet
> >> engineers give certain guarantees. When those are failed to
> >> be met, (s)he is held liable. Maybe it's about time some
> >> "software engineers" were held liable for their unreliable
> >> code in the same way.

> > They are. That's why independent contractors have liability
> > insurance.

> In that case they're *not* liable for their unreliable code.

It depends. For large projects, it's unlikely that the
contractor did the work alone, and it's the prime contractor,
who gave him the job, who's liable. But I've also worked on
smaller projects, where I was responsible, and liable, for all
of the software in the project.

--
James Kanze

== 2 of 11 ==
Date: Thurs, Feb 11 2010 12:33 pm
From: Brian

On Feb 11, 3:07 am, Arved Sandstrom <dces...@hotmail.com> wrote:
>
> Free (as in beer) software brings up an interesting set of arguments. If
> I understand your point as being, if a product is free how can one
> possibly sue the maker of it for flaws in the product? Correct me if I'm
> wrong.
>
> I have my own thoughts on this topic but I simply want to make sure what
> we're discussing.
>

Imagine driving by a house and seeing a car in front with
this sign -- "Free car." It is your responsibility to
check out the car. If I were interested in that car, I'd
talk to the giver of the car, check out the car for
myself (is it stolen?) and then either drive it carefully
to a mechanic or have a mechanic come to the car. After
that I'd be the only one that rides in the car for a
month or two to be more certain that it is in fact a safe
car. As long as the giver reveals any known problems
about the car to me, I don't think there's any basis for
suing him if the car is later found to have a serious problem.

Brian Wood
http://webEbenezer.net
(651) 251-9384

== 3 of 11 ==
Date: Thurs, Feb 11 2010 1:33 pm
From: Andy Champ

Lew wrote:
>
> Andy Champ wrote:
>> In 1982 the manager may well have been right to stop them wasting
>> their time fixing a problem that wasn't going to be a problem for
>> another 18 years or so. The software was probably out of use long
>> before that.
>
> Sure, that's why so many programs had to be re-written in 1999.
>
> Where do you get your conclusions?
>

Pretty well everything I saw back in 1982 was out of use by 1999. How
much software do you know that made the transition?

Let's see.. Operating systems. The PC world was... umm.. CP/M 80?
Maybe MS-Dos 1.0? And by 1999 I was working on drivers for Windows
2000. That's at least two, maybe three depending how you count it,
ground-up re-writes of the OS.

With that almost all the PC apps had gone from 8 bit versions in 64kb of
RAM to 16-bit DOS to Windows 3.1 16-bit with non-preemptive multitasking
and finally to a 32-bit app with multi-threading and pre-emptive
multitasking running in hundreds of megs.

OK, so how about embedded stuff? That dot-matrix printer became a
laserjet. The terminal concentrator lost its RS232 ports, gained a
proprietary LAN, then lost that and got ethernet. And finally
evaporated in a cloud of client-server computing smoke.

I'm not so up on the mainframe world - but I'll be surprised if the
change from dumb terminals to PC clients didn't have a pretty major
effect on the software down the back.

Where do you get your conclusions that there was much software out there
that was worth re-writing eighteen years ahead of time? Remember to
allow for compound interest on the money invested on that development...

Andy.

== 4 of 11 ==
Date: Thurs, Feb 11 2010 1:40 pm
From: Seebs

On 2010-02-11, Andy Champ <no.way@nospam.invalid> wrote:
> Where do you get your conclusions that there was much software out there
> that was worth re-writing eighteen years ahead of time? Remember to
> allow for compound interest on the money invested on that development...

I'm using tens of thousands of lines of code right now that are over twenty
years old. It's called "OS X", and it contains a large hunk of code that
was written either at Berkeley in the 80s or at NeXT in the 80s.

We're still using classes with names like "NSString", where "NS" stands for
NeXTStep. You know, the company that folded something like fifteen years
ago, and wrote this stuff originally prior to 1990?

Heck, I have code *I personally wrote* 19 years ago and which I still use.
It was last touched in any way in 1998, so far as I can tell. It's been
untouched ever since, *because it works correctly*.

And honestly, here's the big thing:

In reality, I do not think that writing things correctly costs that much
more. Because, see, it pays off in debugging time. The rule of thumb they
use at $dayjob is that in the progression from development to testing and
then to users, the cost of fixing a bug goes up by about a factor of 10
at each level. That seems plausible to me. So if I spend an extra day
on a project fixing a couple of bugs, those bugs would probably cost about
10 days total people-time if caught in testing, and 100 if caught by
our customers. And 1000+ if caught by their customers.

This is why I have successfully proposed "this is too broken to fix, let's
build a new one from scratch" on at least one occasion, and gotten it done.

-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

== 5 of 11 ==
Date: Thurs, Feb 11 2010 1:49 pm
From: "Bo Persson"

MarkusSchaber wrote:
> Hi,
>
> On 10 Feb., 22:53, Andy Champ <no....@nospam.invalid> wrote:
>> Can any locksmith or
>> burglar alarm maker guarantee that a building will withstand all
>> attacks for 12 months? _That_ is the equivalent of withstanding
>> all virus attacks for 12 months - and it's on a far simpler system.
>
> Maybe not the locksmith itself, but there are insurance companies
> which calculate how high the risk is, and they take that liability.
>
> For locks, cars, even airplanes, insurance companies do that all the
> time. But there are only a few cases where this is done for
> software.

Is it? What about the software that controls the locks, cars, and
airplanes?

Bo Persson

== 6 of 11 ==
Date: Thurs, Feb 11 2010 2:17 pm
From: Wojtek

Andy Champ wrote :
> Lew wrote:
>>
>> Andy Champ wrote:
>>> In 1982 the manager may well have been right to stop them wasting their
>>> time fixing a problem that wasn't going to be a problem for another 18
>>> years or so. The software was probably out of use long before that.
>>
>> Sure, that's why so many programs had to be re-written in 1999.
>>
>> Where do you get your conclusions?
>>
>
> How much software do you know that made the transition?

> I'm not so up on the mainframe world

Yup. Made lots of money transitioning mainframe apps.

--
Wojtek :-)

== 7 of 11 ==
Date: Thurs, Feb 11 2010 2:28 pm
From: Lew

Andy Champ wrote:
>>> In 1982 the manager may well have been right to stop them wasting
>>> their time fixing a problem that wasn't going to be a problem for
>>> another 18 years or so. The software was probably out of use long
>>> before that.

Lew wrote:
>> Sure, that's why so many programs had to be re-written in 1999.
>>
>> Where do you get your conclusions?

Andy Champ wrote:
> Pretty well everything I saw back in 1982 was out of use by 1999. How
> much software do you know that made the transition?

Pretty much everything I saw back in 1982 is in production to this day, never
mind 1999.

Pretty much everything that had Y2K issues in 1999 was in production since the
1980s or earlier. By the 90s, more software was written without that bug.

Again, why do you think Y2K was such an issue, if affected software had gone
out of production by then?

> Let's see.. Operating systems. The PC world was... umm.. CP/M 80? Maybe
> MS-Dos 1.0? And by 1999 I was working on drivers for Windows 2000.
> That's at least two, maybe three depending how you count it, ground-up
> re-writes of the OS.

PCs were not relevant in 1982. PCs largely didn't have Y2K issues; it was
mainly a mainframe issue.

> With that almost all the PC apps had gone from 8 bit versions in 64kb of
> RAM to 16-bit DOS to Windows 3.1 16-bit with non-preemptive multitasking
> and finally to a 32-bit app with multi-threading and pre-emptive
> multitasking running in hundreds of megs.

Largely irrelevant to the discussion of Y2K issues, which were a mainframe
issue for the most part.

PCs were not in common use in 1982.

> OK, so how about embedded stuff? That dot-matrix printer became a
> laserjet. The terminal concentrator lost its RS232 ports, gained a
> proprietary LAN, then lost that and got ethernet. And finally
> evaporated in a cloud of client-server computing smoke.

Not relevant to the discussion of Y2K issues.

> I'm not so up on the mainframe world - but I'll be surprised if the
> change from dumb terminals to PC clients didn't have a pretty major
> effect on the software down the back.

This was mainframe stuff. Most PC software didn't have Y2K bugs, and there
weren't PCs in common use in 1982.

PCs have had negligible effect on mainframe applications, other than to
provide new ways of feeding them.

> Where do you get your conclusions that there was much software out there
> that was worth re-writing eighteen years ahead of time? Remember to
> allow for compound interest on the money invested on that development...

Software development costs are inversely proportional to the fourth power of
the time allotted. That's way beyond the inflation rate.

Y2K repair costs were inflated by the failure to deal with them early, not
reduced.

The point of my example wasn't that Y2K should have been handled earlier, but
that the presence of the bug was not due to developer fault but management
decision, a point you ignored.

--
Lew

== 8 of 11 ==
Date: Thurs, Feb 11 2010 3:49 pm
From: Flash Gordon

Andy Champ wrote:
> Lew wrote:
>>
>> Andy Champ wrote:
>>> In 1982 the manager may well have been right to stop them wasting
>>> their time fixing a problem that wasn't going to be a problem for
>>> another 18 years or so. The software was probably out of use long
>>> before that.
>>
>> Sure, that's why so many programs had to be re-written in 1999.
>>
>> Where do you get your conclusions?
>>
>
> Pretty well everything I saw back in 1982 was out of use by 1999. How
> much software do you know that made the transition?

<snip>

I know there is software flying around today that is running on Z80
processors (well, the military variant of them) and the plan in the late
90s was for it to continue for another 20 years (I don't know the
details, but a customer signed off on some form of ongoing support
contract). Admittedly the software I used was not doing date processing
(apart from the test rigs, which used the date on printouts, which I
tested to "destruction" which turned out to be 2028).

So yes, software from the 80s is still in active use today in the
embedded world and planned to be in use for a long time to come.

> I'm not so up on the mainframe world - but I'll be surprised if the
> change from dumb terminals to PC clients didn't have a pretty major
> effect on the software down the back.
>
> Where do you get your conclusions that there was much software out there
> that was worth re-writing eighteen years ahead of time? Remember to
> allow for compound interest on the money invested on that development...

Remember to allow for the fact that software does continue to be used
for a *long* time in some industries.
--
Flash Gordon

== 9 of 11 ==
Date: Thurs, Feb 11 2010 4:15 pm
From: Wojtek

Lew wrote :
> The point of my example wasn't that Y2K should have been handled earlier, but
> that the presence of the bug was not due to developer fault but management
> decision, a point you ignored.

At the time (70's etc) hard drive space was VERY expensive. All sorts
of tricks were being used to save that one bit of storage. Remember
COBOL's packed decimal?

So the decision to drop the century from the date was not only based on
management but on hard economics.

Which, I will grant, is not a technical decision, though the solution
was...

And at the time Y2K was created it was not a bug. It was a money saving
feature. Probably worth many millions.

--
Wojtek :-)

== 10 of 11 ==
Date: Thurs, Feb 11 2010 5:07 pm
From: Lew Pitcher

On February 11, 2010 19:15, in comp.lang.c, nowhere@a.com wrote:

> Lew wrote :
>> The point of my example wasn't that Y2K should have been handled earlier,
>> but that the presence of the bug was not due to developer fault but
>> management decision, a point you ignored.
>
> At the time (70's etc) hard drive space was VERY expensive. All sorts
> of tricks were being used to save that one bit of storage. Remember
> COBOL's packed decimal?

Packed decimal (the COBOL COMP-3 datatype) wasn't a "COBOL" thing; it was an
IBM S370 "mainframe" thing. IBM's 370 instructionset included a large
number of operations on "packed decimal" values, including data conversions
to and from fixedpoint binary, and math operations. IBM's COBOL took
advantage of these facilities with the (non-ANSI) COMP-3 datatype.

As for Y2K, there was no "space advantage" in using COMP-3, nor was there an
overriding datatype-reason to store dates in COMP-3. While "space
requirements" are often given as the reason for the Y2K truncated dates,
the truncation usually boiled down to three different reasons:
1) "That's what the last guy did" (maintaining existing code and design
patterns),
2) "We'll stop using this before it becomes an issue" (code longevity), and
3) "We will probably rewrite this before it becomes an issue"
(designer/programmer "laziness").

Space requirements /may/ have been the initial motivation for truncated
dates, but that motivation ceased being an issue in the 1970's, with
cheap(er) high(er) density data storage.

FWIW: I spent 30+ years designing, writing, and maintaining S370 Assembler
and COBOL programs for a financial institution. I have some experience in
both causing and fixing the "Y2K bug".

> So the decision to drop the century from the date was not only based on
> management but on hard economics.
>
> Which, I will grant, is not a technical decision, though the solution
> was...
>
> And at the time Y2K was created it was not a bug.

I agree.

> It was a money saving feature. Probably worth many millions.

I disagree. It was a money-neutral feature (as far as it was a feature) that
would have (and ultimately did) cost millions to change.

Alone, it didn't save much (there's enough wasted space at the end of each
of those billions of mainframe records (alignment issues, don't you know)
to easily have accommodated two more digits (one 8-bit byte) in each
critical date recorded).

The cost would have been in time and manpower (identifying, coding, testing,
& conversion) to expand those date fields after the fact. And, that's
exactly where the Y2K costs wound up. /That's/ the expense that management
didn't want in the 70's and 80's (and got with interest in the 90's).

--
Lew Pitcher
Master Codewright & JOAT-in-training | Registered Linux User #112576
Me: http://pitcher.digitalfreehold.ca/ | Just Linux: http://justlinux.ca/
---------- Slackware - Because I know what I'm doing. ------

== 11 of 11 ==
Date: Thurs, Feb 11 2010 6:06 pm
From: Seebs

On 2010-02-12, Lew Pitcher <lpitcher@teksavvy.com> wrote:
> Space requirements /may/ have been the initial motivation for truncated
> dates, but that motivation ceased being an issue in the 1970's, with
> cheap(er) high(er) density data storage.

Furthermore, what with the popularity of 30-year mortgages, people were
dealing with Y2K in or before 1970...

==============================================================================
TOPIC: So I want to exhaust a lot of memory
http://groups.google.com/group/comp.lang.c/t/efd5686c57529f9b?hl=en
==============================================================================

== 1 of 2 ==
Date: Thurs, Feb 11 2010 12:49 pm
From: Eric Sosman

On 2/11/2010 3:24 PM, Ian Collins wrote:
> Eric Sosman wrote:
>> [... library may have undocumented internal dependencies ...]
>
> While I agree with Eric's comments, in practice I have never had
> problems substituting my own allocator for testing and in some embedded
> targets, production code. In the hosted world, many (if not all?) Unix
> like systems provide a choice of alternative allocators to meet specific
> needs (debug, efficient multi-threading). [...]

Yes. As I said, the memory manager may be the most frequently
replaced piece of the Standard library, and implementors won't make
it difficult to do so unless they've got good reasons.

However, there's a terminology quibble: If a platform provides
half a dozen different versions of malloc() et al., I think the
Standard's view would be that it's providing half a dozen different
C implementations. In particular, if something in the library needs
a back door into realloc(), all the provided realloc() variants will
have that back door -- and it still needn't be documented. The
implementors are the folks who provide all the parts, and should
be expected to provide compatible parts -- but they don't have to
tell you how to machine your own substitutes.

For example, some C implementations provide functions like
mallinfo(), mallopt(), posix_memalign(), and so on. If a program
uses these extensions, they're unlikely to work with some random
re-implementation of malloc(), calloc(), realloc(), and free().

> So while in theory there is no guarantee, in practice it will work.

Yes. Up to a reasonable point, at any rate.

--
Eric Sosman
esosman@ieee-dot-org.invalid

== 2 of 2 ==
Date: Thurs, Feb 11 2010 1:14 pm
From: ImpalerCore

On Feb 11, 3:14 pm, ImpalerCore <jadil...@gmail.com> wrote:
> On Feb 11, 1:49 pm, Eric Sosman <esos...@ieee-dot-org.invalid> wrote:
>
>
>
> > On 2/11/2010 12:01 PM, ImpalerCore wrote:
>
> > > [...]
> > > I can ensure that my library interface uses the set of my_malloc,
> > > my_realloc, my_free, and my_calloc functions, but what do I do about
> > > malloc and friends' influence on the standard library or 3rd party
> > > libraries?
>
> > That's one of the reasons the Standard says it's undefined
> > behavior if you try to substitute your own function for part of
> > the Standard library. The library may have internal links between
> > its parts, and those mechanisms are not standardized and need not
> > even be disclosed. For example, fflush(NULL) flushes all open
> > streams whose most recent operation was output: Something must be
> > going on behind the scenes to get this to work, and the details of
> > that "something" are the implementation's business.
>
> > Do malloc(), calloc(), realloc(), and free() have such internal
> > links? They're obviously connected to each other, but do they have
> > connections to other pieces of the implementation? The Standard
> > doesn't say that they do -- but it doesn't say that they don't,
> > either, so you substitute for them at your peril. Perhaps the code
> > that runs before main() or during program termination "knows" things
> > about their data structures. Maybe there's a special "back door"
> > that delivers page-aligned I/O buffers for fopen(). Maybe ...
>
> > ... which is sort of too bad, because of all the pieces of the
> > Standard library one would like to be able to override, the memory
> > manager is surely the most tempting. Implementors know this, so
> > they're unlikely to put roadblocks in the way just to make trouble.
> > But if there's a good reason (on some platform) for malloc() et al.
> > to have internal connections elsewhere, they'll be there. All I
> > can suggest is careful study of each implementation's documentation,
> > plus some testing and crossing of fingers.
>
> Thanks for your insight into the issues. I don't have an intention of
> overwriting the local standard library's malloc implementation, but
> I'll be happy to let a dmalloc or similar library do it for debugging
> purposes.
>
>
>
> > > Some of my library functions are designed not to return an error code,
> > > but it may have an internal out-of-memory error. An example would be
> > > my_list_insert_front:
>
> > > my_list_t* my_list_insert_front( my_list_t*, void* object );
>
> > > It's possible that the dynamic allocation of the my_list_t node fails,
> > > but usage of the function dictates that the result is assigned back
> > > the list pointer. If an out-of-memory error occur, I can't return
> > > NULL or I'd lose the list. I can have the user rely on checking errno
> > > for ENOMEM, which seems acceptable but maybe not the best method. I'm
> > > not fond style-wise of the version that returns an int and takes a
> > > my_list_t**, even though the return value method of error checking is
> > > generally superior; at this point I would still prefer to check errno
> > > to catch internal list node allocation failures. This isn't the only
> > > point in my library interface that has this problem, and internally,
> > > I'm still conflicted on this issue.
>
> > The errno mechanism is creaky, or even crufty, and (IMHO) should
> > not be employed as a channel for success/failure indications. Use it
> > to provide additional information about a failure that's indicated
> > some other way.
>
> This is my general feeling as well.
>
> > > Does the C standard define whether malloc forces errno to ENOMEM or
> > > some equivalent on an out-of-memory error, or is it a convenience of
> > > the malloc implementation? I've not been able to accurately determine
> > > this from my limited reading.
>
> > The Standard does not require a failed malloc() to set errno at
> > all, much less to set it to any particular value. Further, the
> > Standard does not forbid a *successful* malloc() from setting errno.
>
> I feel more confident now that relying on errno is a bad idea. It
> sounds like to preserve the interface, I'll have to mimic a "errno"
> state that will act in a similar manner as malloc implementations that
> set errno to ENOMEM. Since my custom wrapper reference the global
> function table, that is a place I can embed this "errno" like boolean
> state. My malloc wrappers can update that state correctly and
> independently of errno by just comparing the result of malloc internal
> call generated by calling the custom allocator's malloc through the
> table's function pointer. It allows me to keep the prototype for
> my_list_insert_front the same, and check for memory error using the
> state stored in the function table.
>
> i.e.
>
> struct my_allocator_ftable
> {
> void* (*malloc) ( size_t size );
> void* (*realloc)( void* p, size_t size );
> void (*free) ( void* p );
> void* (*calloc) ( size_t n, size_t size );
> my_bool e_out_of_memory;};
>
> typedef struct my_allocator_ftable my_allocator_ftable_t;
>
> static my_allocator_ftable_t my_private_allocator_ftable =
> {
> standard_malloc,
> standard_realloc,
> standard_free,
> standard_calloc,
> FALSE
>
> };
>
> /* Used to set the custom allocator. */
> void my_allocator_set_ftable( 4 function pointers );
>
> void* my_malloc( size_t size )
> {
> void* mem = NULL;
>
> if ( size )
> {
> mem = my_private_allocator_ftable.malloc( size );
> if ( mem ) {
> my_private_allocator_ftable.e_out_of_memory = TRUE;
> }
> }
>
> return mem;
>
> }

Found a small error in my_malloc; I have the e_out_of_memory condition
inverted.

void* my_malloc( size_t size )
{
void* mem = NULL;

if ( size )
{
mem = my_private_allocator_ftable.malloc( size );
if ( !mem ) {
my_private_allocator_ftable.e_out_of_memory = TRUE;
}
}

return mem;
}

> I'll have to try it out and see how it goes. Thanks for your input.
>
> Best regards,
> John D.
>
> > --
> > Eric Sosman
> > esos...@ieee-dot-org.invalid
>
>

==============================================================================
TOPIC: void * arithmetic
http://groups.google.com/group/comp.lang.c/t/a33b3b6b3dba34c8?hl=en
==============================================================================

== 1 of 5 ==
Date: Thurs, Feb 11 2010 1:04 pm
From: Seebs

On 2010-02-11, Keith Thompson <kst-u@mib.org> wrote:
> A signed 32-bit integer cannot have the value 0xFFFFFFFF.
>
> Do you mean 0xFFFFFFFF to refer to a certain bit pattern rather than a
> value?

Er, yeah. I meant "representation", specifically.

I'm off my brain all this week, I think, came down with a cold and been
sleeping funny hours.

== 2 of 5 ==
Date: Thurs, Feb 11 2010 1:41 pm
From: "bartc"

"Keith Thompson" <kst-u@mib.org> wrote in message
news:lnmxzfedwz.fsf@nuthaus.mib.org...
> Seebs <usenet-nospam@seebs.net> writes:
>> On 2010-02-11, Balban <bilgehan.balban@gmail.com> wrote:
>>> On my compiler (gcc), if I add an integer value to a void pointer the
>>> integer is interpreted as signed instead of unsigned. Is this expected
>>> behavior?
>>
>> There is no expected behavior, pointer arithmetic is not defined at all
>> for void pointers. :P
>>
>> That said, I don't understand how you're making the distinction. Imagine
>> that you have a 32-bit integer of some unspecified type, and it has the
>> value 0xFFFFFFFF, and you add it to a 32-bit pointer. It is going to do
>> the same thing whether it's signed or unsigned.
>
> A signed 32-bit integer cannot have the value 0xFFFFFFFF.

Seems to work though:

#include <stdio.h>
#include <limits.h>

int main(void){
signed int a=0xFFFFFFFF;

printf("Bits = %d\n",(sizeof a)*CHAR_BIT);
printf("A = %X\n",a);
}

--
Bartc

== 3 of 5 ==
Date: Thurs, Feb 11 2010 1:54 pm
From: Keith Thompson

"bartc" <bartc@freeuk.com> writes:
> "Keith Thompson" <kst-u@mib.org> wrote in message
> news:lnmxzfedwz.fsf@nuthaus.mib.org...
>> Seebs <usenet-nospam@seebs.net> writes:
>>> On 2010-02-11, Balban <bilgehan.balban@gmail.com> wrote:
>>>> On my compiler (gcc), if I add an integer value to a void pointer the
>>>> integer is interpreted as signed instead of unsigned. Is this expected
>>>> behavior?
>>>
>>> There is no expected behavior, pointer arithmetic is not defined at all
>>> for void pointers. :P
>>>
>>> That said, I don't understand how you're making the distinction. Imagine
>>> that you have a 32-bit integer of some unspecified type, and it has the
>>> value 0xFFFFFFFF, and you add it to a 32-bit pointer. It is going to do
>>> the same thing whether it's signed or unsigned.
>>
>> A signed 32-bit integer cannot have the value 0xFFFFFFFF.
>
> Seems to work though:
>
> #include <stdio.h>
> #include <limits.h>
>
> int main(void){
> signed int a=0xFFFFFFFF;
>
> printf("Bits = %d\n",(sizeof a)*CHAR_BIT);
> printf("A = %X\n",a);
> }

Depends on what you mean by "work".

Assuming int is 32 bits on your system, initializing ``a'' with
the expression 0xFFFFFFFF does not store the value 0xFFFFFFFF
(equivalently, 4294967295) in ``a''. Instead, it stores the result
of converting 0xFFFFFFFF from unsigned int to int. That result
is implementation-defined. (It's probably -1 on your system;
it is on mine.)

Then in your printf call, you use a "%X" format, which expects a value
of type unsigned int, with an argument of type int. There's a special
rule that says you can get away with this if the value is within the
range of values representable either as int or as unsigned int, but
that's not the case here, so strictly speaking I think the behavior is
undefined. In practice, the printed result is very likely to be what
you would get by interpreting the representation of the int object
``a'' (with whatever value resulted from the conversion) as it were an
object of type unsigned int.

It's hardly surprising that the output is "A = FFFFFFFF",
but it's certainly not required, and it doesn't indicate that
you've managed to store the value 0xFFFFFFFF in ``a''. In fact,
it's simply not possible to do so.

(Also, you're using "%d" with a size_t argument in the first
printf call. And let me repeat my plea not to use the name "a" for
variables in small demo programs; it makes the code more difficult
to talk about. "x" or "n" would be fine.)

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

== 4 of 5 ==
Date: Thurs, Feb 11 2010 2:17 pm
From: ImpalerCore

On Feb 11, 2:12 pm, Balban <bilgehan.bal...@gmail.com> wrote:
> Hi,
>
> On my compiler (gcc), if I add an integer value to a void pointer the
> integer is interpreted as signed instead of unsigned. Is this expected
> behavior?

As other people have said, addition is not supported by the standard
using void*. gcc allows you to add to void pointers by implicitly
casting the pointer to unsigned char* (or maybe char*, I'm not really
sure) type. I actually used to do it until recently. Now I cast the
pointer before performing the addition; it plays nicer with -ansi -
pedantic.

i.e.

typedef unsigned char byte;

void* track_malloc( size_t size )
{
void* mem = NULL;
void* p = NULL;

p = malloc( size + sizeof( size_t ) );
if ( p )
{
*((size_t*)p) = size;
mem = (byte*)p + sizeof( size_t );
}

return mem;
}

void track_free( void* p )
{
void* actual_p = NULL;
size_t p_size = 0;

if ( p )
{
actual_p = (byte*)p - sizeof( size_t );
p_size = *((size_t*)actual_p);
free( actual_p );
printf( "track_free [p,size] = [%p,%u]\n", actual_p, p_size );
}
}

Best regards,
John D.

> Thanks,
>
> Bahadir

== 5 of 5 ==
Date: Thurs, Feb 11 2010 4:54 pm
From: gil_johnson

On Feb 11, 1:12 pm, Balban <bilgehan.bal...@gmail.com> wrote:
> Hi,
>
> On my compiler (gcc), if I add an integer value to a void pointer the
> integer is interpreted as signed instead of unsigned. Is this expected
> behavior?
>
> Thanks,
>
> Bahadir

I'm not an expert, but it seems to be a good idea to me. I can imagine
that you might calculate a new offset into a data structure, relative
to the current position, and have it come out negative. It would be
simpler to add the negative than force the answer to be positive and
keep track of addition vs subtraction.
As others have noted, the behavior is not specified by the standard, I
think this may be an example of "Do the least surprising thing."
Gil

==============================================================================
TOPIC: pointers
http://groups.google.com/group/comp.lang.c/t/8e78c8f2011f3891?hl=en
==============================================================================

== 1 of 2 ==
Date: Thurs, Feb 11 2010 2:12 pm
From: "Default User"

Seebs wrote:

> On 2010-02-11, Tom St Denis <tom@iahu.ca> wrote:
> > In what way are you not a troll?
>
> One presumes that he can't read, at some fairly fundamental level.
> Google "alexia" sometime and compare it to his posts.

All I know is that in 2008, Bill seemed to know how fread() worked just
fine, now he doesn't. Trolling. Regressing. Take your pick. Either way,
a complete waste of time replying.

Brian

--
Day 374 of the "no grouchy usenet posts" project

== 2 of 2 ==
Date: Thurs, Feb 11 2010 2:45 pm
From: Richard Heathfield

Tom St Denis wrote:
<snip>
> Granted his tone isn't negative, he's still a waste of time.

Well, *he* isn't a waste of time. But I agree with what I am sure you
actually meant - i.e. it's a waste of time to read his articles. What I
don't understand is why you feel it necessary to waste everyone's time
by telling us what we already know. :-)

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within

==============================================================================
TOPIC: Warning to newbies
http://groups.google.com/group/comp.lang.c/t/9597fd702985dff4?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Feb 11 2010 2:23 pm
From: Richard Heathfield

spinoza1111 wrote:
> On Feb 9, 5:56 pm, Tim Streater <timstrea...@waitrose.com> wrote:
>> On 08/02/2010 23:33, Richard Heathfield wrote:
>>
>>> Seebs wrote:
>>>> On 2010-02-08, Tim Streater <timstrea...@waitrose.com> wrote:
>>>>> Only if you like slapstick. Personally, I can't stand it.
>>>> I like very little of it. It is very rarely done well.
>>> Check out Norman Wisdom. He does it very well indeed.
>> Fractionally before my time (I think).
>>
>> I saw Dudley Moore in some film (Arthur??) in which he is by a swimming
>> pool where there is a small table with a phone on it (not in the pool :-)
>>
>> Needless to say, and entirely predictably, he tangles himself up in the
>> phone line and goes into the pool. With the phone.
>>
>> It was very well done, I have to say, it looked almost entirely natural.
>> But the predictability of it turned it into a yawn.
>
> These idiots are airing their deep knowledge of TV.

I've skipped past most of the spinoza1111 junk that's accumulated in the
day or two I've been away, but I found the above sentence particularly
amusing. I have practically zero knowledge of TV, since I don't watch TV
(except accidentally, e.g. in friends' houses), and have not done so
for many a long year. My knowledge of TV is quite possibly the
shallowest of almost any adult in the developed world.

> Meanwhile there
> was as they wrote a massive bug in my code just waiting, like a nubile
> female, for them to find her, and garner glory and get a reason to
> caper and gibber, and laugh at me to their heart's content.

Bugs in your code aren't sufficient justification for capering and
gibbering. If they were, I'd be a gibbering wreck by now. No, they are
opportunities for you to learn. Since you have in the past proved
unwilling to learn from your bugs, I tend only to point out the first
one I see (if that).

<snip>

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within

==============================================================================
TOPIC: The C FAQ
http://groups.google.com/group/comp.lang.c/t/b75c0ae09abf3345?hl=en
==============================================================================

== 1 of 3 ==
Date: Thurs, Feb 11 2010 2:37 pm
From: Richard Heathfield

bartc wrote:
>
<snip>

>
> Anyone who sees the MSDOS stuff in the FAQ is going to wonder how old,
> out-of-date, irrelevant and unreliable the rest of it is going to be.

What if they also saw questions about using C with more modern operating
systems? Then what would they all wonder?

If you think the FAQ is unreliable, by the way, I suggest you send a
patch to Steve Summit. Did you have a specific question in mind whose
answer you consider unreliable?

>
> The C FAQ is obviously just a static file, but if it was a dynamic
> resource, the MSDOS queries would have long vanished into the archive
> section.

And there they would remain... undeleted. Since the C FAQ is (as you
rightly say) relatively static, however, the archive section is kinda
all mixed up with the non-archive section. I seem to recall that
system-specific questions are in their own chapter anyway, so what's the
problem?

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within

== 2 of 3 ==
Date: Thurs, Feb 11 2010 2:42 pm
From: Richard Heathfield

jacob navia wrote:
> Dennis K a �crit :
>>
>> The Pharoah's are all dead, but we still treasure their mummified bodies.
>>
>
> Yes. You, and all "regs" here, still treasure the mummified body of
> MSDOS.
>
> The catastrophic impression that a FAQ fulll of MSDOS references

But the clc FAQ isn't *full* of MSDOS references.

You would be far more impressive if you could stick to facts.

<snip>

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within

== 3 of 3 ==
Date: Thurs, Feb 11 2010 6:14 pm
From: "bartc"

"Richard Heathfield" <rjh@see.sig.invalid> wrote in message
news:oZ6dnfHDudMsG-nWnZ2dnUVZ8gKdnZ2d@bt.com...
> bartc wrote:
>>
> <snip>
>
>>
>> Anyone who sees the MSDOS stuff in the FAQ is going to wonder how old,
>> out-of-date, irrelevant and unreliable the rest of it is going to be.
...
> If you think the FAQ is unreliable, by the way, I suggest you send a patch
> to Steve Summit. Did you have a specific question in mind whose answer you
> consider unreliable?

I'm talking about what newcomers might think after glancing through section
19, which could do with an overhaul.

The rest of it seems sound enough to me, but I'm not an expert, so wouldn't
know if some of the advice written in 1995 (or perhaps earlier) is still
good 15 years later.

--
Bartc

==============================================================================
TOPIC: representation of register's fields
http://groups.google.com/group/comp.lang.c/t/ae3b5f4e576cfbd1?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Feb 11 2010 6:17 pm
From: "Mark"

James Kuyper wrote:
> That was, as I've already stated, my best guess as to what you were
> doing - I don't need to have such things explained to me.

Sorry, didn't mean to offend you, I thought there was some misunderstanding
about my environment, that's why I was gaving some trivial details.

> I was making two points: standard C provides no mechanism for defining
> such a constant. Therefore, you must be using an implementation-
> specific extension to C.
[snip]

And now I'm confused with your words. Just to make it clear and clean, here
is more accurate example, and we assume 'phy' and 'reg' can't contain values
bigger then 28 and 31 respectively:

#define REG_0 0x01u
#define SMI_READ 0u

unsigned int val, reg, phy;

val = (reg << 16) | (0u << 21) | (phy << 24) | (SMI_READ << 29) | (1u <<
30);

*(volatile unsigned int *)(REG_0) = val; /* XX */

The XX-marked statement is valid in the standard C, and doesn't require any
compiler's extensions, am I right ?

--
Mark
--
comp.lang.c.moderated - moderation address: clcm@plethora.net -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line. Sorry.

==============================================================================

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

twitter

Thursday, February 11, 2010

comp.lang.c - 25 new messages in 7 topics - digest

0 Comments:

Post a Comment

About Me

Previous Posts