From: Borut R. <bor...@si...> - 2004-03-04 20:29:03
|
>> Now the qestion is, what do you mean with "make it portable": > Make it conforming with the C-standard. Here is an other possibility, which is so obvious, that I didn't saw it: to include alloca.c from libiberty to the project. alloca.c is conforming with the C-standard, so everything is OK. >> And now my opinion about alloca: >> - You are definetely right: alloca() isn't defined in the standard, but I >> don't konw for any compiler (or C library, to be more precise), >> which doesn't support it. >??? >What about i586-mingw32msvc-gcc? i586-mingw32msvc-gcc supports alloca. If this wouldn't be true, sdcc wouldn't compile at all on mingw32. The problem is, in which header file is declared: on *nix it is in stdlib.h (or in an other header file, which is included in stdlib), on WIN32 is in malloc.h. >> - "The alloca function is machine and compiler dependent. On many >> systems its implementation is buggy. Its use is discouraged." This might >> be true, but I'm using alloca on WIN32 (VC), Linux (gcc) and HP-UX >> (aCC, cc), and I didn't notice any problems. So I think that the info >> from the man page might be slightly out of date, >How can you know this? Know what? That it might be true or that it works on systems I'm using? I'm pretty sure abut both ;-) For the info from the man page I wrote "might be", which indicates that I don't know ;-) >>May be the man page is up to date, and alloca() will >>disappear in gcc 4.x. Do you think it's wise to ignore manuals? The manuals are written by humans like you and me. Nobody of us can predict the future. Standards are also changing and it is possible that some features are dropped. Alloca is already widely used, so I doubt that it will disappear in the near future. And again, there is alloca.c, which can be a replacement for built-in allocas. >> To summarize: I think that we shold act pragmatically. >I agree, but the question is: what's pragmatic? It's a fact that alloca() >makes problems with one of our compilers on the CF. We can't blame the >compiler, because alloca() isn't part of the C standard. IMO the pragmatic >solution is to get rid of alloca(). Finally this shouldn't be such a big >problem. As I already motioned, the problem is not in alloca, but in included files. If malloc.h would be included in support/Util/system.h in case of _WIN32, the warning will disappear. But then you'll complain that malloc.h is not supported by a standard... Maybe I should just add a line void *alloca(size_t size); and everything will be OK ;-) >Just to say "it works for me and my current compilers" is quite short >sighted. I definitely agree with this. I just expressed my experience, which is far from the completeness... >Do you know what kind of computers or compilers will come within >the next couple of years? Today's experience is that software lives much >longer than it was expected at the time when it was written. Look at aslink >or asx8051: their roots go back to a time where the "PC" was not yet born. The emphasis is on "lives". That means that it is developing all the time. And I think that I actually already did some changes in both aslink and asx8051 to support spaces in file names. So also allocas can be changed to something standardized, for example variable-length arrays when they will be mature enough. And an other thing about aslink and asx8051: they are both using K&R style for parameter declaration in function definition, which I'm afraid that will be dropped in some of future C standards (which is already done by C++ and, guess what? by sdcc too ;-) But this doesn't mean that they will die. We will just correct them. The same thing was already done in gcc sources. >Do you know anything about DECUS C, PDOS C or Symantec C? Actually not. Do you? ;-) >The only way to write long-lived and problem-free software, which will run >with all existing and most future CPUs, computers, OSs and compilers, is to >follow the standard. You forgot to add my statement "Follow standards as much as possible,..." when you cited me ;-) >This is the reason why many open source projects demand >to follow the standard. And so does SDCC. Just as a curiosity: when I run $find . -type f -name '*.c*' -exec grep 'alloca *(' {} \; in gcc CVS tree, the result was, (guess what? I was surprised as much as you are): 251 So gcc is probably a software which will not live for long, especially if they'll drop alloca in gcc 4.x and make a suicide ;-))) I tried the same on sdcc, and the result is (an other surprise): 15 You can subtract the one that I "produced", and the number is 14. So sdcc will also not survive, not because of sdcc itself (or maybe I will be the guilty one), but because sdcpp will die. And this is the difference between the theory and practice I was talking about. But, in the end, I don't think that there is a big difference between my and your opinion. We both agree that standards should be followed as much as possible. This is why they are here, isn't it? There is a small difference in how strict we should be. OK, this is a long letter, it took quite some time to write it, but I enjoyed writing it. Bernhard, if you want to continue with this discussion, it will be probably better to switch to the private channel. With hope that I didn't offend anybody, Borut |