WIKI errors for sift.c example in IFFParse Library docs
WIKI errors for sift.c example in IFFParse Library docs
I copied the sift.c example in the WIKI "IFFParse Library" docs, removed some binary codes from the sources and attempted to perform a simple compile with "GCC sift.c -o sift" and found the following errors:
sift.c:(.text+0x220): undefined reference to `OpenClipboard'
sift.c:(.text+0x4e0): undefined reference to `CloseClipboard'
sift.c:64: warning: assignment from incompatible pointer type
I had to make the following changes:
Changed 'OpenClipboard' to 'IIFFParse->OpenClipboard'
Changed 'CloseClibboard' to 'IIFFParse->CloseClipboard'
Changed 'IIFFParse = (struct IFFPaseIFace*)' to 'IIFFParse = (struct IFFParseIFace*)' [missing an 'r' character]
The sift program works with the above corrections in the source but the output could be made a little clearer with the findings on seperate lines. The bugs in the source are minor but it wouldn't hurt to fix the sift.c source so that it will compile correctly.
sift.c:(.text+0x220): undefined reference to `OpenClipboard'
sift.c:(.text+0x4e0): undefined reference to `CloseClipboard'
sift.c:64: warning: assignment from incompatible pointer type
I had to make the following changes:
Changed 'OpenClipboard' to 'IIFFParse->OpenClipboard'
Changed 'CloseClibboard' to 'IIFFParse->CloseClipboard'
Changed 'IIFFParse = (struct IFFPaseIFace*)' to 'IIFFParse = (struct IFFParseIFace*)' [missing an 'r' character]
The sift program works with the above corrections in the source but the output could be made a little clearer with the findings on seperate lines. The bugs in the source are minor but it wouldn't hurt to fix the sift.c source so that it will compile correctly.
AmigaOne X1000 with 2GB memory - OS4.1 FE
Re: WIKI errors for sift.c example in IFFParse Library docs
Fixed the errors, thanks for reporting.
The Rear Window blog
AmigaOne X5000 @ 2GHz / 4GB RAM / Radeon RX 560 / ESI Juli@ / AmigaOS 4.1 Final Edition
SAM440ep-flex @ 667MHz / 1GB RAM / Radeon 9250 / AmigaOS 4.1 Final Edition
AmigaOne X5000 @ 2GHz / 4GB RAM / Radeon RX 560 / ESI Juli@ / AmigaOS 4.1 Final Edition
SAM440ep-flex @ 667MHz / 1GB RAM / Radeon 9250 / AmigaOS 4.1 Final Edition
- salass00
- AmigaOS Core Developer
- Posts: 530
- Joined: Sat Jun 18, 2011 3:12 pm
- Location: Finland
- Contact:
Re: WIKI errors for sift.c example in IFFParse Library docs
Anyone else think the indentation style of those iffparse examples should be changed to something more easily readable?
I'm fine with either:
or:
The current style gives me a headache just from looking at it.
I'm fine with either:
Code: Select all
if (expression) {
blah();
}
Code: Select all
if (expression)
{
blah();
}
Re: WIKI errors for sift.c example in IFFParse Library docs
I find that having braces on seperate lines easier to read and follow:salass00 wrote:Anyone else think the indentation style of those iffparse examples should be changed to something more easily readable?
Code: Select all
if (expression)
{
blah();
}
It would be nice if the examples in the WIKI could be downloaded as source files. Whenever I copy & paste code from the WIKI, I end up removing some binary codes and reformatting the code.
AmigaOne X1000 with 2GB memory - OS4.1 FE
- tonyw
- AmigaOS Core Developer
- Posts: 1479
- Joined: Wed Mar 09, 2011 1:36 pm
- Location: Sydney, Australia
Re: WIKI errors for sift.c example in IFFParse Library docs
Don't get me started on code formatting. I have been involved in many formal and informal projects over the years, and those that have laid-down standards usually have little in common. Such rules as indenting, variable/function names, order of function parameters, use of white space and format of comments all vary from one project to another. Then, of course, there are the local rules for documentation. It all takes up valuable time adapting one's habits to a new set of rules each time.
Two things that annoy me particularly (for purely aesthetic reasons) are:
1. variable names all in lower case, the words joined by underscores (such as "engine_water_temperature"); and
2. braces not matched vertically (as Fredrik quoted above).
I agree with xenic on this one. When reading someone else's code, I don't like having to search earlier rows of text to find the start of this block. I like to be able to see the opening brace, at the same indent as the close.
Two things that annoy me particularly (for purely aesthetic reasons) are:
1. variable names all in lower case, the words joined by underscores (such as "engine_water_temperature"); and
2. braces not matched vertically (as Fredrik quoted above).
I agree with xenic on this one. When reading someone else's code, I don't like having to search earlier rows of text to find the start of this block. I like to be able to see the opening brace, at the same indent as the close.
cheers
tony
tony
- salass00
- AmigaOS Core Developer
- Posts: 530
- Joined: Sat Jun 18, 2011 3:12 pm
- Location: Finland
- Contact:
Re: WIKI errors for sift.c example in IFFParse Library docs
I don't really have a preference either way regarding variable naming, but in my own code I usually use all lower case letters for local variables and reserve use of capitalised names for global variables to keep them somewhat separate.tonyw wrote: 1. variable names all in lower case, the words joined by underscores (such as "engine_water_temperature"); and
Personally I find it just as easy to match the closing brace to the corresponding if, while, for, do or switch statement.2. braces not matched vertically (as Fredrik quoted above).
In fact one might argue that having the opening brace on the same line as the if, while or whatever makes it more clear that it's not just a solitary block for limiting the scope of variables defined in it.
Also you didn't say what you think of the style on the wiki which is:
Code: Select all
if (expression)
{
blah();
}
- tonyw
- AmigaOS Core Developer
- Posts: 1479
- Joined: Wed Mar 09, 2011 1:36 pm
- Location: Sydney, Australia
Re: WIKI errors for sift.c example in IFFParse Library docs
Ye gods, I didn't notice that one. Looks awful. In my view, the outside of the opening brace is at the same level as the preceding statement. Inside the brace is one level higher, so it should (IMHO) read:
Code: Select all
if (expression)
{
blah();
}
cheers
tony
tony
- broadblues
- AmigaOS Core Developer
- Posts: 600
- Joined: Sat Jun 18, 2011 2:40 am
- Location: Portsmouth, UK
- Contact:
Re: WIKI errors for sift.c example in IFFParse Library docs
That gets my down vote too!salass00 wrote:tonyw wrote:
Also you didn't say what you think of the style on the wiki which is:Code: Select all
if (expression) { blah(); }
Cooincidentally I just worked through some code, which whilst other well written used that indenting style, and I was twitching like madman by the end of it
There seem a wide slection of style in that wiki article.
There tools for fixing suich things in src code not sure you could easily apply them to the wiki though.
- broadblues
- AmigaOS Core Developer
- Posts: 600
- Joined: Sat Jun 18, 2011 2:40 am
- Location: Portsmouth, UK
- Contact:
Re: WIKI errors for sift.c example in IFFParse Library docs
Indeed, it's because the wiki code converts spaces to nonbreaking spaces to preserve the code layout, would be useful to be able to download or copy unmodified src clips to the clipboard, I guess a different wiki "code plugin" might be required for that.xenic wrote: It would be nice if the examples in the WIKI could be downloaded as source files. Whenever I copy & paste code from the WIKI, I end up removing some binary codes and reformatting the code.
Re: WIKI errors for sift.c example in IFFParse Library docs
@Thread
[LURKINGMODE=OFF]
It's been a while since I last posted anything on any Amiga-related thread: due to circumstances I've become a lurker por the past one-and-a-half year. In that timespan I've changed address more often then in the preceding 6 decades and hence, I don't care to unpack and setup my X5000 again or any time soon.
However, Tony wrote and this piqued my interest:
3. Function names all in lower case, the words joined by underscores (such as "_all_i_wanted_to_know_about_sex_"). This seems a bit of a trend in places like Github. I'm all for a style ressembling an oral command as "<Command>_<Subject>", like "Get_Record", or "Calculate_NettResult". Function names in Amiga's libraries look quite like this.
4. braces not only matched vertically, but utilising the odd columns (1, 3, 5, etc., etc.), while text starts on even columns.
5. Allways use braces! Even if it encloses only one line of text.
6. use of tabs. As a great mind once remarked about not setting the tabwidth to 4 (or was it 8?) is like redefining pi to something different from 3.14. His observation was quite right, but his conclusion did not match mine. My stance on this one is: don't use tabs, but spaces as they are unubiquitous.
Ok guys, that's it. Back to:
[LURKINGMODE=ON]
[LURKINGMODE=OFF]
It's been a while since I last posted anything on any Amiga-related thread: due to circumstances I've become a lurker por the past one-and-a-half year. In that timespan I've changed address more often then in the preceding 6 decades and hence, I don't care to unpack and setup my X5000 again or any time soon.
However, Tony wrote and this piqued my interest:
I couldn't agree more and, being a stickler for coding style, I'd like to take the opportunity to add some more:Two things that annoy me particularly (for purely aesthetic reasons) are:
1. variable names all in lower case, the words joined by underscores (such as "engine_water_temperature"); and
2. braces not matched vertically (as Fredrik quoted above).
3. Function names all in lower case, the words joined by underscores (such as "_all_i_wanted_to_know_about_sex_"). This seems a bit of a trend in places like Github. I'm all for a style ressembling an oral command as "<Command>_<Subject>", like "Get_Record", or "Calculate_NettResult". Function names in Amiga's libraries look quite like this.
4. braces not only matched vertically, but utilising the odd columns (1, 3, 5, etc., etc.), while text starts on even columns.
5. Allways use braces! Even if it encloses only one line of text.
6. use of tabs. As a great mind once remarked about not setting the tabwidth to 4 (or was it 8?) is like redefining pi to something different from 3.14. His observation was quite right, but his conclusion did not match mine. My stance on this one is: don't use tabs, but spaces as they are unubiquitous.
Ok guys, that's it. Back to:
[LURKINGMODE=ON]
X5000, appears to be sick. Dismantled jan 1, 2024.
Dead MicroA1
A1200 in ElBox, c/w Blizzard '040 @ 50MHz + SCSI module, ZIV-board c/w (o.a.) cv64/3d + flickerdoubler + FastATA-ZIV + Lots of SCSI gear, sitting idle.
RaspBerry Pi 2B, 3B, 4B/4Gb, 4B/8Gb
OrangePi 5+ 8Gb
ACER Windows 10
Dead MicroA1
A1200 in ElBox, c/w Blizzard '040 @ 50MHz + SCSI module, ZIV-board c/w (o.a.) cv64/3d + flickerdoubler + FastATA-ZIV + Lots of SCSI gear, sitting idle.
RaspBerry Pi 2B, 3B, 4B/4Gb, 4B/8Gb
OrangePi 5+ 8Gb
ACER Windows 10