linux-ntfs-dev — Development discussions and bug reports.

Re: [Linux-NTFS-Dev] Re: unnamed structures

[Anton A. <ai...@ca...>]

On Sun, 29 Feb 2004, john doe wrote:
> > What compiler are you trying to use?!?
>
> I was using gcc 3.2.3 (mingw port) and 3.2

And they don't support -fm-extensions?  I am very surprised!

> I should try others versions as well, but thats not the point here, I
> have orginally asked why wasn't the patch applied to both the kernel
> driver & the library, that wasn't quite answared yet.

I did it in the kernel because people kept complaining that it didn't
compile for them and I got bored of answering the support requests so I
did the change.  For the user space code it is very different.  We have
./configure which detects what compiler you are using and tells you to get
lost if your compiler doesn't support -fms-extensions.  And that's fine
with me.  Unnamed structs and unions are damn nice C feature and I can't
understand why the gcc mob don't just support them straight out.  They are
IMO incredibly useful in making code look nice and simple and give some
inteligence to the compiler.  I personally really, really like them.
That's why they are there and I would really like them to stay there but
if you have a good reason why they don't work for you then I am willing to
have them removed like I did in the kernel.  I still don't understand why
you have a problem with the unnamed structs and unions considering your
gcc should support them...  Could you explain?

> I am willing to take the job, once you choose the naming format.

Cool.  How about you do the first part using the same naming format as in
the kernel for a start?  I am not convinced I want the existing code
modified to use abstractions beyond that otherwise the kernel code would
look completely different to the utilities and I _hate_ those
functions/macros that hide structures in them and considering I am really
the only person working on the kernel driver I am not going to start using
something I hate there...  (-;

Best regards,

	Anton
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net
WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/

[Linux-NTFS-Dev] Re: unnamed structures

[john d. <uv...@us...>]

>>1) unnamed structures
>>2) packing enums
>>3) incomptability with mingw's header files to libntfs's include files
>>(for example: GUID is declared in both)

> Why did you fail?  What does GUI writing have to do with compiler
> switches?!?  Also the packing enums are definitely here to stay otherwise
> you would violate the on-disk format and converting them to defines
> breaks type checking and typing in general.

I am not complaining on the enums, that is another problem I should 
solve, without changing the code.

> What compiler are you trying to use?!?

I was using gcc 3.2.3 (mingw port) and 3.2

I should try others versions as well, but thats not the point here, I 
have orginally asked why wasn't the patch applied to both the kernel 
driver & the library, that wasn't quite answared yet.

I am willing to take the job, once you choose the naming format.

best regards.

Re: [Linux-NTFS-Dev] Re: unnamed structures

[Szakacsits S. <sz...@si...>]

On Sun, 29 Feb 2004, Anton Altaparmakov wrote:
> 
> Yes but potential for using the wrong one is huge, like accidentally
> using ntfs_attr_size_set() instead of ntfs_attr_datasize_set() or
> whatever...

Supposed we chose a confusing name, compiling can indeed fail. But if we
have an easy to remember convention then this could be minimized.
 
> Also the header files would become quite huge 

Probably over a hundred new lines must be added, sure.

> as all such functions must be inlined otherwise the speed impact would
> be unnacceptable.

An alternative is using macros as reiserfs does e.g.

#define set_sd_v2_gid(sd,n)            ((sd)->sd_gid = cpu_to_le32((n)))
#define sd_v2_atime(sd)                (le32_to_cpu((sd)->sd_atime))
#define set_sd_v2_atime(sd,n)          ((sd)->sd_atime = cpu_to_le32((n)))
#define sd_v2_mtime(sd)                (le32_to_cpu((sd)->sd_mtime))

E.g. endianess mess

                  reiserfsprogs   ntfsprogs
	headers:      127            207
	code   :        0            809

After a conversion ntfsprogs could have almost the same excellent metrics
as reiserfsprogs.

> The other conversion is something I am not very happy about.  It is far
> too much abstraction and code obfuscation for my tastes...  

The difference between the two obfuscation methods is that, now there are
obfuscations _everywhere_, and in the other case there would be _only_ in
the headers. 

> So I strongly suggest to do them completely separately, 

That's a good idea.

> especially as it is very likely that a flame fest will happen about
> what to call the abstracted functions 

I don't things so :)

	Szaka

Re: [Linux-NTFS-Dev] Re: unnamed structures

[Szakacsits S. <sz...@si...>]

On Sun, 29 Feb 2004, Anton Altaparmakov wrote:
> On Sun, 29 Feb 2004, Szakacsits Szabolcs wrote:
> >   now: 	     a->data_size = cpu_to_le32(le32_to_cpu(a->data_size) + 2);
> >   you want:  a->n.data_size = cpu_to_le32(le32_to_cpu(a->n.data_size + 2);
> >   could be:  ntfs_attr_datasize_set(a, ntfs_attr_datasize_get(a) + 2);
> >
> > The last one might be even more simple if it made sense in the future,
> >
> > 	ntfs_attr_datasize_add(a, 2);
> 
> And another problem with this is that all functions beginninf with
> ntfs_attr_() 

The above naming was just one _example_, personally I wouldn't call it
that way, I just tried to guess your taste and failed again :)

Hiding the details was the point, not the naming.

I don't really care how you want to call them because I think any name
would be better than the current way. We could call them NTFS_ATTR_,
NTFS_SET_ATTR_, NTFS_SETATTR_, NTFS_ATTREC_, NTFS_ATTR_REC_,
ntfs_set_attr_, ntfs_setattr_, ntfs_attrec_, ntfs_attr_rec_,
ntfs_attribute_record_, ntfs_arecord_, ntfs_arec, ntfs_ar_, etc.

> operate on ntfs_attr structures and not on ATTR_RECORD structures.  

So perhaps something like NTFS_ATTR, NTFS_ATTREC_, ntfs_attrec would make
more sense. But I thought it's pointless to discuss naming until

	1) there is an agreement to go ahead with anything

	2) john (or somebody) undertakes to do them

     Szaka

Re: [Linux-NTFS-Dev] Re: unnamed structures

[Anton A. <ai...@ca...>]

On Sun, 29 Feb 2004, Szakacsits Szabolcs wrote:
> I CC: this to linux-ntfs-dev, the origin of the email is here,
>
>  http://sourceforge.net/forum/forum.php?thread_id=1030888&forum_id=44084

This says:

>as you know, libntfs requires -fms-extensions to compile, mainly due to
>anonymous structures.
>there is a simple way of fixing it (surprisingly: naming the structures),
>thus making the code a bit more portable.
>I tried to write a GUI frontend to libntfs, and failed mainly due to 3
>reasons:
>1) unnamed structures
>2) packing enums
>3) incomptability with mingw's header files to libntfs's include files
>(for example: GUID is declared in both)

Why did you fail?  What does GUI writing have to do with compiler
switches?!?  Also the packing enums are definitely here to stay otherwise
you would violate the on-disk format and converting them to defines
breaks type checking and typing in general.

What compiler are you trying to use?!?

Best regards,

	Anton
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net
WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/

Re: [Linux-NTFS-Dev] Re: unnamed structures

[Anton A. <ai...@ca...>]

On Sun, 29 Feb 2004, Szakacsits Szabolcs wrote:
>   now: 	     a->data_size = cpu_to_le32(le32_to_cpu(a->data_size) + 2);
>   you want:  a->n.data_size = cpu_to_le32(le32_to_cpu(a->n.data_size + 2);
>   could be:  ntfs_attr_datasize_set(a, ntfs_attr_datasize_get(a) + 2);
>
> The last one might be even more simple if it made sense in the future,
>
> 	ntfs_attr_datasize_add(a, 2);

And another problem with this is that all functions beginninf with
ntfs_attr_() operate on ntfs_attr structures and not on ATTR_RECORD
structures.  So you can't use ntfs_attr_*() for such an abstraction
otherwise it would be far too confusing...

Best regards,

	Anton
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net
WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/

Re: [Linux-NTFS-Dev] Re: unnamed structures

[Anton A. <ai...@ca...>]

On Sun, 29 Feb 2004, Szakacsits Szabolcs wrote:
> In more verbose, what could be beneficial for everybody is
>
> 	1) making the unnamed -> named conversion
> AND
> 	2) encapsulating the details in macros or inline functions
>
> Let's see an example:
>
>   now: 	     a->data_size = cpu_to_le32(le32_to_cpu(a->data_size) + 2);
>   you want:  a->n.data_size = cpu_to_le32(le32_to_cpu(a->n.data_size + 2);

No, you don't.  (-;  I am only willing to accept naming the structs and
unions if and only if it is done in _exactly_ the same way as the kernel
NTFS driver.  Otherwise it would be far too confusing for anyone working
on both or copying code from one to the other.

>   could be:  ntfs_attr_datasize_set(a, ntfs_attr_datasize_get(a) + 2);
>
> The last one might be even more simple if it made sense in the future,
>
> 	ntfs_attr_datasize_add(a, 2);
>
> This has the following advantages:
>
> 	- better portability
> 	- more readable
> 	- more reliable code (endianness can't be forgotten)
> 	- with well chosen names, much less to type/read/print

Yes but potential for using the wrong one is huge, like accidentally
using ntfs_attr_size_set() instead of ntfs_attr_datasize_set() or
whatever...

Also the header files would become quite huge as all such functions must
be inlined otherwise the speed impact would be unnacceptable.

> Would you be willing to do both conversations, not only the unnamed one?

I would be very happy to take patches for the unnamed conversion as long
as it is done like in the kernel.

The other conversion is something I am not very happy about.  It is far
too much abstraction and code obfuscation for my tastes...  So I strongly
suggest to do them completely separately, especially as it is very likely
that a flame fest will happen about what to call the abstracted functions
once such a patch appears...

Best regards,

	Anton
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net
WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/

[Linux-NTFS-Dev] Re: unnamed structures

[Szakacsits S. <sz...@si...>]

Hello,

I CC: this to linux-ntfs-dev, the origin of the email is here,

 http://sourceforge.net/forum/forum.php?thread_id=1030888&forum_id=44084

On Sat, 28 Feb 2004, john doe wrote:

> I'm directing this message to you becouse I assume it would 
> not have (much) public intrest.

It has, we discuss issues.
 
> I followed you advice, and went through the dev's mailing list
> archive, till I found a year back discussion about the
> -fms-extensions. due to that thread I noticed that the kernel 
> driver is actually not using unnamed structures, but the patch 
> was not applied to the lib.
> 
> I havn't found a direct reason in the mailing-list, but that 
> thread, and your reply of "would make developers life harder" 
> implied that you (the main developers) simply do not like that 
> fix.
> 
> I am only holding on to that matter becouse I can't use for 
> some reason the "-fms-extensions", but still want the ability 
> to distibute my code with the standard library (not a hevily 
> patched one).
> 
> can you please enlight me about that matter?

  http://marc.theaimsgroup.com/?l=linux-ntfs-dev&m=104878222521219&w=2

My recommended solution was here,

  http://marc.theaimsgroup.com/?l=linux-ntfs-dev&m=104887740430985&w=2

In more verbose, what could be beneficial for everybody is 

	1) making the unnamed -> named conversion
AND 
	2) encapsulating the details in macros or inline functions

Let's see an example:

  now: 	     a->data_size = cpu_to_le32(le32_to_cpu(a->data_size) + 2);
  you want:  a->n.data_size = cpu_to_le32(le32_to_cpu(a->n.data_size + 2);
  could be:  ntfs_attr_datasize_set(a, ntfs_attr_datasize_get(a) + 2);

The last one might be even more simple if it made sense in the future,

	ntfs_attr_datasize_add(a, 2);

This has the following advantages:

	- better portability
	- more readable
	- more reliable code (endianness can't be forgotten) 
	- with well chosen names, much less to type/read/print

Would you be willing to do both conversations, not only the unnamed one?

Cheers,
	Szaka

Re: [Linux-NTFS-Dev] Re: mount on Promise Tech Fasttrack RAID

[Anton A. <ai...@ca...>]

On Sun, 29 Feb 2004, Szakacsits Szabolcs wrote:
> I CC: this email to linux-ntfs-dev also, maybe others have more ideas
> about your RAID [google could help also(?), I don't have the time for it
> right now, sorry]. More details about the issue are here:
>
>   http://sourceforge.net/forum/forum.php?thread_id=1030819&forum_id=44085
>
> What we figured out was that NTFS couldn't be mounted because of
>
>   Loading $MFT... ntfs_pread(): Entering for pos 0xc0000000, count 0x400.
>   Error: $MFT has invalid magic.
>
> No wonder, the $MFT started as complete garbage:
>
> 0000000: 54ae 3d2f fd14 9a6d c863 2491 472a 8b4d  T.=/...m.c$.G*.M
> 0000010: 47de 8a7d f0a3 2a81 0403 33cd 83b3 0591  G..}..*...3.....
> 0000020: 2924 5c67 620f aa05 8cc4 1974 ec3f 2c70  )$\gb......t.?,p
> 0000030: ea38 592a 3bcd 9737 f6b4 9b28 1e6e c360  .8Y*;..7...(.n.`
> 0000040: 87ee 40b0 6b43 80a0 7a0a 2a59 0f64 1052  ..@.kC..z.*Y.d.R
>
> > The system stalls for a bit and then i get:
> > dd: reading `/dev/hdf1': Input/output error
>
> OK, I'm figuring out what's going on. You have four 20 GB disks. Your NTFS
> is clearly 60 GB (from the NTFS metadata), so it spans 3 disk. But it's
> not dynamic disk. Apparently they are put together a different way under
> Windows and Linux. Well, actually it isn't put together on Linux at all,
> /dev/hdf1 is only 20 GB. 40 GB is "missing".
>
> This looks to be either a Promise kernel driver bug or a Promise driver
> configuration problem. Or maybe you should configure the 3 disks as 1
> using software RAID?
>
> > After this, i get the same error if I try to do any of the command
> > (mft.bin,mftmir.bin, or bootsect.bin)
> > I need to reboot for mft.bin to dd properly
>
> This definitely looks to be a Promise driver problem.

The important question is how the RAID was created.  Was is

1) created using the Promise BIOS

2) created within Windows NT4 or earlier

3) some other way - please specify

If 1) the Linux promise driver is apparently not functioning correctly or
you are trying to open the wrong partition device (I thought ATA RAID
drivers had their devices under something like /dev/ataraid/blah or
something).

If 2) you need to use Linux Software RAID (the MD driver) to connect the
pieces of your array correctly and then you can mount the /dev/md0 device
(or /dev/md1, etc, whatever you configured the array as) with the Linux
NTFS driver.  If this is the case see our instructions on how to configure
the driver.  They can be found in the Linux kernel 2.6 sources in
Documentation/filesystems/ntfs.txt or online here:
http://linux-ntfs.bkbits.net:8080/ntfs-2.6/anno/Documentation/filesystems/ntfs.txt@1.41?nav=index.html|src/.|src/Documentation|src/Documentation/filesystems

If 3) we need more information.

Best regards,

	Anton
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net
WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/

[Linux-NTFS-Dev] Re: mount on Promise Tech Fasttrack RAID

[Szakacsits S. <sz...@si...>]

Hi,

I CC: this email to linux-ntfs-dev also, maybe others have more ideas
about your RAID [google could help also(?), I don't have the time for it
right now, sorry]. More details about the issue are here:

  http://sourceforge.net/forum/forum.php?thread_id=1030819&forum_id=44085

What we figured out was that NTFS couldn't be mounted because of 

  Loading $MFT... ntfs_pread(): Entering for pos 0xc0000000, count 0x400.
  Error: $MFT has invalid magic.

No wonder, the $MFT started as complete garbage:

0000000: 54ae 3d2f fd14 9a6d c863 2491 472a 8b4d  T.=/...m.c$.G*.M
0000010: 47de 8a7d f0a3 2a81 0403 33cd 83b3 0591  G..}..*...3.....
0000020: 2924 5c67 620f aa05 8cc4 1974 ec3f 2c70  )$\gb......t.?,p
0000030: ea38 592a 3bcd 9737 f6b4 9b28 1e6e c360  .8Y*;..7...(.n.`
0000040: 87ee 40b0 6b43 80a0 7a0a 2a59 0f64 1052  ..@.kC..z.*Y.d.R

> The system stalls for a bit and then i get:
> dd: reading `/dev/hdf1': Input/output error

OK, I'm figuring out what's going on. You have four 20 GB disks. Your NTFS
is clearly 60 GB (from the NTFS metadata), so it spans 3 disk. But it's
not dynamic disk. Apparently they are put together a different way under
Windows and Linux. Well, actually it isn't put together on Linux at all,
/dev/hdf1 is only 20 GB. 40 GB is "missing".

This looks to be either a Promise kernel driver bug or a Promise driver
configuration problem. Or maybe you should configure the 3 disks as 1
using software RAID?

> After this, i get the same error if I try to do any of the command 
> (mft.bin,mftmir.bin, or bootsect.bin)
> I need to reboot for mft.bin to dd properly

This definitely looks to be a Promise driver problem.
 
Cheers,
	Szaka

[Linux-NTFS-Dev] Re: ntfsck

[Anton A. <ai...@ca...>]

On Sat, 28 Feb 2004, Szakacsits Szabolcs wrote:
> On Thu, 26 Feb 2004, Anton Altaparmakov wrote:
> There is a high demand for a stable resizer with the relocation support.
> Current ntfsresize 1.9-BETA is stable, still no error was reported over
> the last 3 months. The things needed to be added are
>
> 	- support the very rare cases left
> 	- make code usable for others as functions
>
> Both of the aboves need heavier changes and although they aren't really in
> functionality but they are error-prone. I'm afraid it could just
> invalidate the last 3 months successful testing phase.
>
> What's missing to be released as stable? Well, mostly
>
> 	1) discriminated exit codes thus tools using it would know
>            what to do or report to users without parsing the ntfsresize
>            output.

That is not a showstopper for a stable release IMO.

> 	2) if an on-going resize fails for some reason then the modified
>            $BITMAP won't be saved. This isn't very healthy but
>
> 	     a) users and integrators are always adviced to make an
>                 explicite resize test run. If that succeds then the
>                 real resize must succeed also. So they can end up in this
>                 situation only if they don't follow the advice.
>
>              b) if they ignored the documents/advices and ended up in
>                 this situation then the scheduled chkdsk should be able
>                 to correct $BITMAP. In my experience, it was always able
>                 to do it correctly.
>
> My question is what way to proceed? Focus/make a stable release before
> heavier changes? If yes then should I implement the $BITMAP saving for
> that release?

I suggest stable release sooner rather than later.  Remember: release
often is the secret to success.  (-:  I would suggest to either implement
the $BITMAP saving OR to bolt a big fat warning when ntfsresize aborts
saying something like: WARNING! WARNING! WARNING! You MUST let Windows
chkdsk test and repair this partition as it has been left in an
inconsistent state!  Do not attempt to write anything to this partition
until it has been repaired by chkdsk!  Failure to do so will result in
total loss of all data on the partition in the worst case!  You have been
warned.

If that doesn't scare people into letting chkdsk work on the
partition nothing will.  (-:

Whatever you decide just let me know when you are ready and I will make
the release.

Best regards,

	Anton
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net
WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/

Re: [Linux-NTFS-Dev] how to fix bugs

[Anton A. <ai...@ca...>]

On Sat, 28 Feb 2004, Szakacsits Szabolcs wrote:
> On Sat, 28 Feb 2004, Andras Erdei wrote:
> > >btw. Could you try playing with the settings on your mailer? pine can't
> > >open your emails saying "invalid quoted printable character" or something
> > >like that.
>
> I have that problem also but I thought it is introduced somewhere after
> sourceforge and my MUA by a filter/whatever software.
>
> > i was told the culprit is actually the mailing list; it attached an
> > advertisement to the end of my posting:
>
> Who told you? I'm not sure that's right. No problems with others emails
> but always with yours. So unless ads are customised based on names ...
>
> However on the other hand, if I get emails from you directly then they are
> always ok. So something should be wrong around sourceforge indeed ...
>
> > don't think i can do anything about that
>
> Turning off quoted-printable Content-Transfer-Encoding? It looks broken in
> your emails, at least when they arrive here, e.g.:

Yes, that is the only difference between mails coming for example from
Szaka and from Andras:  Andras emails have the line:

Content-Transfer-Encoding: quoted-printable

in the headers and this seems to break pine whether it is SF.net's fault
or not I don't know.  Possibly SF.net footer contains characters that are
not valid in QP encoding.  So Szaka is probably right that if you, Andras,
switch of QP encoding in your mailer the problem would go away.  Worth a
try I would suggest...

>    [Error: Formatting error: Non-hexadecimal character in QP encoding]

Yes, same here.

Best regards,

	Anton
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net
WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/

[Linux-NTFS-Dev] ntfsck

[Szakacsits S. <sz...@si...>]

On Thu, 26 Feb 2004, Anton Altaparmakov wrote:
> Yes, we could really, really do with a fully featured ntfsfsk utility in
> ntfsprogs.  It wouldn't even need to fix anything, just report errors...
> Unfortunately noone's ever written one.  )-:

I use this over a year

	% alias ntfsck="ntfsresize -fi"

Exit value is 0 if NTFS is OK and 1 otherwise, reporting what was the
problem.

It found _many_ problems during development, in libntfs, RAM problems, IDE
cable problem, etc.

I'm planning to make the consistency check part of ntfsresize to be a
function because I'd like resizing this way in the future.

	consistency check
	resize
	consistency check

But I have a dilemma at present to proceed. 

There is a high demand for a stable resizer with the relocation support.
Current ntfsresize 1.9-BETA is stable, still no error was reported over
the last 3 months. The things needed to be added are

	- support the very rare cases left
	- make code usable for others as functions

Both of the aboves need heavier changes and although they aren't really in
functionality but they are error-prone. I'm afraid it could just
invalidate the last 3 months successful testing phase.

What's missing to be released as stable? Well, mostly

	1) discriminated exit codes thus tools using it would know
           what to do or report to users without parsing the ntfsresize
           output.

	2) if an on-going resize fails for some reason then the modified 
           $BITMAP won't be saved. This isn't very healthy but

	     a) users and integrators are always adviced to make an
                explicite resize test run. If that succeds then the
                real resize must succeed also. So they can end up in this
                situation only if they don't follow the advice.

             b) if they ignored the documents/advices and ended up in
                this situation then the scheduled chkdsk should be able 
                to correct $BITMAP. In my experience, it was always able
                to do it correctly.

My question is what way to proceed? Focus/make a stable release before
heavier changes? If yes then should I implement the $BITMAP saving for
that release?

	Szaka

Re: [Linux-NTFS-Dev] how to fix bugs

[Szakacsits S. <sz...@si...>]

On Sat, 28 Feb 2004, Andras Erdei wrote:
> 
> >btw. Could you try playing with the settings on your mailer? pine can't 
> >open your emails saying "invalid quoted printable character" or something 
> >like that.

I have that problem also but I thought it is introduced somewhere after
sourceforge and my MUA by a filter/whatever software.

> i was told the culprit is actually the mailing list; it attached an
> advertisement to the end of my posting:

Who told you? I'm not sure that's right. No problems with others emails
but always with yours. So unless ads are customised based on names ...

However on the other hand, if I get emails from you directly then they are
always ok. So something should be wrong around sourceforge indeed ...

> don't think i can do anything about that

Turning off quoted-printable Content-Transfer-Encoding? It looks broken in
your emails, at least when they arrive here, e.g.:

------------------------------------------------------->
On 28 Feb 2004 09:51:46 +0000, Anton Altaparmakov <ai...@ca...> =
wrote:

>Yes, I think so. That is how K&R wrote it and how I have (almost) always=
=20
>seen it written, at least in the kernel.
[...]
<-------------------------------------------------------

And this is what I can only see in pine usually:

   [Error: Formatting error: Non-hexadecimal character in QP encoding]

	Szaka

Re: [Linux-NTFS-Dev] how to fix bugs

[Andras E. <and...@in...>]

On 28 Feb 2004 12:00:19 +0000, Anton Altaparmakov <ai...@ca...> =
wrote:

>btw. Could you try playing with the settings on your mailer? pine can't=20
>open your emails saying "invalid quoted printable character" or =
something=20
>like that.

i was told the culprit is actually the mailing list; it attached an
advertisement to the end of my posting:

> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=1356&alloc_id438&op=3Dclick
> _______________________________________________
> Linux-NTFS-Dev mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linux-ntfs-dev

and the URL in that (http://ads.osdn.com/?ad_id<here>) contains
the strange character :O)

don't think i can do anything about that


br,
andras

Re: [Linux-NTFS-Dev] Re: circular include

[Anton A. <ai...@ca...>]

On Feb 28 2004, Andras Erdei wrote:

> On 28 Feb 2004 09:46:35 +0000, Anton Altaparmakov <ai...@ca...> =
> wrote:
> 
> >I agree.  Would you like to send me patches doing the _fwd.h thing?
> 
> i can do it, but if i'm doing it, it'll take a while (i don't yet
> know by heart which types one header uses from another), so don't
> expect the patches this weekend -- or should i send them one by one?

Send one by one or whenever - up to you.  Nobody is in a hurry here...  (-:

> ps: do you prefer having forwarding headers, or handcoded forward-
> declarations?

I prefer the _fwd.h approach you described. (But I may be misunderstanding 
the question.)

Best regards,

Anton

-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net
WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/

Re: [Linux-NTFS-Dev] how to fix bugs

[Anton A. <ai...@ca...>]

On Feb 28 2004, Andras Erdei wrote:

> On 28 Feb 2004 09:51:46 +0000, Anton Altaparmakov <ai...@ca...> =
> wrote:
> 
> >Yes, I think so. That is how K&R wrote it and how I have (almost) always=
> =20
> >seen it written, at least in the kernel.
> 
> [not nipicking, just because the article can be interesting if you
> design/implement libraries]
> 
> actually K&R didn't have const (or volatile or signed), and R wrote
> an article against having them in the language:

Well, my copy of K&R "The C Programmin Language" 2nd Ed has const and 
volatile in it both in the text and in the C spec... Admittedly it is 
marked as new to ANSI in the reference manual.

btw. Could you try playing with the settings on your mailer? pine can't 
open your emails saying "invalid quoted printable character" or something 
like that.

Best regards,

Anton

> 
>  http://www.lysator.liu.se/c/dmr-on-noalias.html
> 
> 
> br,
> andras
> 
> 
> 
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> _______________________________________________
> Linux-NTFS-Dev mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linux-ntfs-dev
> 

-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net
WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/

Re: [Linux-NTFS-Dev] Re: circular include

[Andras E. <and...@in...>]

On 28 Feb 2004 09:46:35 +0000, Anton Altaparmakov <ai...@ca...> =
wrote:

>I agree.  Would you like to send me patches doing the _fwd.h thing?

i can do it, but if i'm doing it, it'll take a while (i don't yet
know by heart which types one header uses from another), so don't
expect the patches this weekend -- or should i send them one by one?


br,
andras

ps: do you prefer having forwarding headers, or handcoded forward-
declarations?

Re: [Linux-NTFS-Dev] how to fix bugs

[Andras E. <and...@in...>]

On 28 Feb 2004 09:51:46 +0000, Anton Altaparmakov <ai...@ca...> =
wrote:

>Yes, I think so. That is how K&R wrote it and how I have (almost) always=
=20
>seen it written, at least in the kernel.

[not nipicking, just because the article can be interesting if you
design/implement libraries]

actually K&R didn't have const (or volatile or signed), and R wrote
an article against having them in the language:

 http://www.lysator.liu.se/c/dmr-on-noalias.html


br,
andras

Re: [Linux-NTFS-Dev] how to fix bugs

[Anton A. <ai...@ca...>]

On Feb 28 2004, Andras Erdei wrote:
[snip]
> type qualifiers always refer to the whole type to the left of them:
> 
> char const * p means a pointer to a constant char (p=3D... ok, *p=3D... =
> not ok)
> char * const p means a constant pointer to a char (p=3D... not ok, =
> *p=3D... ok)

Thanks for the clarification. (-:

> as an exception to the above rule, type qualifiers are also allowed at
> the beginning of a type (when there's nothing left to them), and in this
> special case they modify the type right next to them, so "const int"
> is the same as "int const"
> 
> compilers print qualified types in the first form, because they 
> generate=20 it from some inner representation, and it's easier to always 
> use the=20 general rule
> 
> people have to write "char * const" because there is no alternative, but
> they often prefer "const char *" over "char const *", presumably out of
> tradition (?)

Yes, I think so. That is how K&R wrote it and how I have (almost) always 
seen it written, at least in the kernel.
 
> >Anyway, normally I would write the qualified "const" first, then the =
> rest,=20
> >so I would write
> >
> >const char c;
> >const char *p;
> >const int i[20];
> >
> >etc... as that is how it is usually done in the kernel.
> 
> i don't really care which one i have to use, but unless these conventions
> are written down somewhere, you'll have to flame me about every new line
> of code i write, because i will not know what you expect from me

True but I would just write the code. If nothing else we can always run 
Lindent if we feel the need... (-; I suggest you just look at existing 
libntfs code and try to stick more or less to the same notation and we 
should be fine.

Best regards,

Anton

-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net
WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/

Re: [Linux-NTFS-Dev] Re: circular include

[Anton A. <ai...@ca...>]

On Feb 28 2004, Andras Erdei wrote:
> the reason you felt you need the circles is that sometimes
> a.h needs an incomplete type from b.h and at the same time
> b.h really depends on a.h
>=20
> this is why runlist.h forward declares runlist_element and
> runlist before including attrib.h: attrib.h needs incomplete
> types from runlist.h, and runlist.h depends on attrib.h; but
> you still had to handcode that into runlist.h because circular
> includes don't really solve this problem (1 & 2 means they
> don't do anything at all when they compile)

Correct.
=20
> volume.h similarly forward declares ntfs_volume before including
> other headers; i haven't got further yet :O)
>=20
> using handcoded forward declarations is one option, but afaik
> the canonical (pretty) solution is to provide separate forward
> declaration headers, like
>=20
> runlist_fwd.h:
> typedef struct _runlist_element runlist_element;
> typedef runlist_element runlist;
>=20
> attrib.h:
> #include "runlist_fwd.h"=09<-- instead of "runlist.h"
> ...
>=20
> handcoding the forward declarations into the header
> is perfectly o.k. (although the right place is attrib.h,
> not runlist.h), but having a forwarding header means

I don't want to forward declare runlist stuff in attrib.h. Bound to cause=
=20
headaches later on when somethin in runlist.h gets modified and we have to=
=20
hunt all the other forward declarations. This is why the includes are=20
circular and use header guards.

> - slightly less maintenance (only one file has to be
>   edited when e.g. you add a new type to runlist.h)
>=20
> - slightly faster compilation (user code that only
>   needs the incomplete type can also include the _fwd.h
>   instead of the real one)
>=20
> - imho a bit more clarity

I agree.  Would you like to send me patches doing the _fwd.h thing?

Best regards,

Anton

--=20
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net
WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/

[Linux-NTFS-Dev] found the bug (fwd)

[Anton A. <ai...@ca...>]

---------- Forwarded message ----------
Date: Sat, 28 Feb 2004 08:36:44 +0000 (GMT)
From: "[iso-8859-1] nag talekar" <nsr...@ya...>
To: Anton Altaparmakov <ai...@ca...>
Subject: found the bug

HI....

I found the bug :)
u were right.
i was not doing fixups
now my program is working fine.
thanks for helping
hope to keep in touch with u
thanks again for helping

regards
Nag

=====
With Regards

Nagareshwar

________________________________________________________________________
Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more.
Go to: http://in.insurance.yahoo.com/licspecial/index.html

Re: [Linux-NTFS-Dev] how to fix bugs

[Andras E. <and...@in...>]

On 28 Feb 2004 00:00:41 +0000, Anton Altaparmakov <ai...@ca...> =
wrote:

>I don't think there is a document about such things but my belief has=20
>always been that
>
>const char *
>
>and
>
>char const *
>
>and
>
>char *const
>
>are all different things depending on whether the pointer is const or =
the=20
>referenced memory but maybe I have been wrong all along...

these three are actually two different things :O)

type qualifiers always refer to the whole type to the left of them:

char const * p means a pointer to a constant char (p=3D... ok, *p=3D... =
not ok)
char * const p means a constant pointer to a char (p=3D... not ok, =
*p=3D... ok)

as an exception to the above rule, type qualifiers are also allowed at
the beginning of a type (when there's nothing left to them), and in this
special case they modify the type right next to them, so "const int"
is the same as "int const"

compilers print qualified types in the first form, because they generate=20
it from some inner representation, and it's easier to always use the=20
general rule

people have to write "char * const" because there is no alternative, but
they often prefer "const char *" over "char const *", presumably out of
tradition (?)

>Anyway, normally I would write the qualified "const" first, then the =
rest,=20
>so I would write
>
>const char c;
>const char *p;
>const int i[20];
>
>etc... as that is how it is usually done in the kernel.

i don't really care which one i have to use, but unless these conventions
are written down somewhere, you'll have to flame me about every new line
of code i write, because i will not know what you expect from me


br,
andras

Re: [Linux-NTFS-Dev] Re: circular include

[Andras E. <and...@in...>]

On 27 Feb 2004 23:40:26 +0000, Anton Altaparmakov <ai...@ca...> =
wrote:

>> >volume.h includes inode.h
>> >inode.h includes runlist.h
>> >runlist.h includes volume.h
>>=20
>> runlist.h includes attrib.h
>> attrib.h includes runlist.h
>>=20
>> attrib.h includes volume.h
>> volume.h includes ... <see the first circle>
>>=20
>> is this intentional? should i stop looking for circles?
>
>It is intentional. You will notice that each file references bits from =
the=20
>other file.

sometimes, and almost :O)

e.g. if you remove #include "runlist.h" from attrib.h make will still =
succeed

>There is no way to fix this (feel free to prove me wrong!) short of =
using=20
>only one massive header file...

i think it's easy to prove that it's never needed:

a.h includes b.h
b.h includes a.h

1. assuming no header guards (#ifdef A_H) it's an infite loop
   at compile-time, and it doesn't compile

2. with include guards, when a.h is included in a program, it
   starts by including b.h which does not again include a.h as=20
   the header guard is already declared, but in fact nothing=20
   from a.h has been compiled yet, so if the compile succeeds,
   b.h necessarily hasn't used anything from a.h (so for every=20
   such circle there must be at least one point where it can be=20
   broken up)

the reason you felt you need the circles is that sometimes
a.h needs an incomplete type from b.h and at the same time
b.h really depends on a.h=20

this is why runlist.h forward declares runlist_element and=20
runlist before including attrib.h: attrib.h needs incomplete
types from runlist.h, and runlist.h depends on attrib.h; but=20
you still had to handcode that into runlist.h because circular=20
includes don't really solve this problem (1 & 2 means they=20
don't do anything at all when they compile)

volume.h similarly forward declares ntfs_volume before including=20
other headers; i haven't got further yet :O)

using handcoded forward declarations is one option, but afaik
the canonical (pretty) solution is to provide separate forward=20
declaration headers, like

runlist_fwd.h:
typedef struct _runlist_element runlist_element;
typedef runlist_element runlist;

attrib.h:
#include "runlist_fwd.h"	<-- instead of "runlist.h"
...

handcoding the forward declarations into the header
is perfectly o.k. (although the right place is attrib.h,
not runlist.h), but having a forwarding header means

- slightly less maintenance (only one file has to be
  edited when e.g. you add a new type to runlist.h)

- slightly faster compilation (user code that only
  needs the incomplete type can also include the _fwd.h
  instead of the real one)

- imho a bit more clarity


br,
andras

Re: [Linux-NTFS-Dev] how to fix bugs

[Anton A. <ai...@ca...>]

On Feb 27 2004, Andras Erdei wrote:
> On Thu, 26 Feb 2004 12:21:52 +0100 (MET), Szakacsits Szabolcs =3D
> <sz...@si...> wrote:
> >> > int stoucs( uchar_t * dst, char const * src, int size )
> >
[snip]
> all i found was /usr/src/linux/Documentation/CodingStyle
> but that does not contain anything about * or const:
>=20
> >Code can easily end up in the kernel in the future. The most often used
> >way is this (consider spacing and 'const char' order):
> >
> >=09int stoucs(uchar_t *dst, const char *src, int size)
>=20
> [i'm happy with whatever way of writing const (the compiler
> will spit it out in error messages my way anyways :O), but
> i need the doc to know how i should do things]

I don't think there is a document about such things but my belief has=20
always been that

const char *

and

char const *

and

char *const

are all different things depending on whether the pointer is const or the=
=20
referenced memory but maybe I have been wrong all along...

Anyway, normally I would write the qualified "const" first, then the rest,=
=20
so I would write

const char c;
const char *p;
const int i[20];

etc... as that is how it is usually done in the kernel.

Best regards,

Anton

--=20
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net
WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/