Welcome!

By registering with us, you'll be able to discuss, share and private message with other members of our community.

SignUp Now!

Another help nit

May
12,845
164
"b" isn't mentioned in the table of disk/memory size format flags. I know it's mentioned further on but it belongs in the table.
 
On Tue, 24 Feb 2009 07:04:35 -0600, rconn <> wrote:

|---Quote---
|> "b" isn't mentioned in the table of disk/memory size format flags. I know it's mentioned further on but it belongs in the table.
|---End Quote---
|Since it's ignored (it equals a scale factor of 1) I don't know that
|putting it in the table serves much purpose, but I'll add it to the list.

It seems it **must** be present if you want @FILESIZE to give allocation in
bytes ... @FILESIZE[...,b,a].
--
- Vince
 
On Tue, 24 Feb 2009 09:07:01 -0600, vefatica <> wrote:

||---Quote---
||> "b" isn't mentioned in the table of disk/memory size format flags. I know it's mentioned further on but it belongs in the table.
||---End Quote---
||Since it's ignored (it equals a scale factor of 1) I don't know that
||putting it in the table serves much purpose, but I'll add it to the list.
|
|It seems it **must** be present if you want @FILESIZE to give allocation in
|bytes ... @FILESIZE[...,b,a].

Perhaps you'd change things to allow @FILESIZE[file_spec,,a].
--
- Vince
 
On Tue, 24 Feb 2009 07:04:35 -0600, rconn <> wrote:

|---Quote---
|> "b" isn't mentioned in the table of disk/memory size format flags. I know it's mentioned further on but it belongs in the table.
|---End Quote---
|Since it's ignored (it equals a scale factor of 1) I don't know that
|putting it in the table serves much purpose, but I'll add it to the list.

It seems it **must** be present if you want @FILESIZE to give allocation in
bytes ... @FILESIZE[...,b,a].

That would certainly be true if it weren't that the allocation option was removed a couple of years ago (in order to support /S). I need to update the docs.
 
On Tue, 24 Feb 2009 19:13:54 -0600, rconn <> wrote:

||It seems it **must** be present if you want @FILESIZE to give allocation in
||bytes ... @FILESIZE[...,b,a].
|
|That would certainly be true if it weren't that the allocation option was removed a couple of years ago (in order to support /S). I need to update the docs.

I don't see how they conflict, or even make life difficult for each other. My
(now abandoned) @DU[] had it right from the beginning ... whenever a filesize
was added to the byte total, a number of clusters was added to the cluster total
... a one-liner.

Anyway, if one were interested (as one might be) in the disk space used, bytes
allocated seems a must.
--
- Vince
 
rconn wrote:
| ---Quote (Originally by vefatica)---
| On Tue, 24 Feb 2009 07:04:35 -0600, rconn <> wrote:
|
|| ---Quote---
||| "b" isn't mentioned in the table of disk/memory size format flags.
||| I know it's mentioned further on but it belongs in the table.
|| ---End Quote---
|| Since it's ignored (it equals a scale factor of 1) I don't know that
|| putting it in the table serves much purpose, but I'll add it to the
|| list.
|
| It seems it **must** be present if you want @FILESIZE to give
| allocation in
| bytes ... @FILESIZE[...,b,a].
| ---End Quote---
|
| That would certainly be true if it weren't that the allocation option
| was removed a couple of years ago (in order to support /S). I need
| to update the docs.

The command

echo %@filesize[/s *,b,a] %@filesize[/s *]

indeed returned the same value twice, meaning that the parser accepted the
optional ,a parameter, but the code ignored it. Not up to your usual
standards...
--
Steve
 
Steve Fábián wrote:

> The command
>
> echo %@filesize[/s *,b,a] %@filesize[/s *]
>
> indeed returned the same value twice, meaning that the parser accepted the
> optional ,a parameter, but the code ignored it. Not up to your usual
> standards...

No, both the parser and the code ignored the "a". (Most of the variable
functions ignore any extraneous arguments.

Rex Conn
JP Software
 
vefatica wrote:

> On Tue, 24 Feb 2009 19:13:54 -0600, rconn <> wrote:
>
> ||It seems it **must** be present if you want @FILESIZE to give allocation in
> ||bytes ... @FILESIZE[...,b,a].
> |
> |That would certainly be true if it weren't that the allocation option was removed a couple of years ago (in order to support /S). I need to update the docs.
>
> I don't see how they conflict, or even make life difficult for each other. My
> (now abandoned) @DU[] had it right from the beginning ... whenever a filesize
> was added to the byte total, a number of clusters was added to the cluster total
> ... a one-liner.
>
> Anyway, if one were interested (as one might be) in the disk space used, bytes
> allocated seems a must.

If it was that critical, somebody should have noticed during the past
couple of years ...

Rex Conn
JP Software
 
vefatica wrote:



If it was that critical, somebody should have noticed during the past
couple of years ...

It's becoming increasingly common for bugs and other unfortunate things to go undetected for a long time. There's an awful lot of stuff in TCC. When someone raises a question about some feature, others start playing with that feature and that feature's features come to light. That'll continue.
 
It's becoming increasingly common for bugs and other unfortunate things to go undetected for a long time. There's an awful lot of stuff in TCC. When someone raises a question about some feature, others start playing with that feature and that feature's features come to light. That'll continue.

And it could very well be that folks continues using @FILESIZE[] with "a", thinking it was working since there was no indication that it wasn't!
 
vefatica wrote:
| And it could very well be that folks continues using @FILESIZE[] with
| "a", thinking it was working since there was no indication that it
| wasn't!

That's my fear as well. I have a UDF using ",bc,a".
--
Steve
 

Similar threads

Back
Top