CFML: Bug(s) in ODBC-date/time formatting functions

G'day:
Whilst testing some TestBox glitches (more about that in a later article, but the executive summary is "it's good!"), I noticed some dodgy behaviour in the ODBC-date/time-formatting functions. In both ColdFusion and Railo.

TBH, I have no idea why we are using createOdbcDate() in our codebase at all... we do not use ODBC drivers. And that'd be the only time one would want to use these functions. Equally, they're only really useful if one wants to pass dates to DBs as strings, hard-coded into the SQL statement, and this should be actively discouraged in favour of passing parameters; and for that a native CFML date/time object is fine.

Firstly... what the hell are these functions for? (that's rhetorical... I'm about to tell you...) ODBC defines a string format one can use to unambiguously represent a date value. The details are in the Microsoft docs: "ODBC Datetime Format", but a summary is this:

{ literal_type 'constant_value' }
literal_type
Specifies the type of the escape sequence. Timestamps have three literal_type specifiers:

d

date only

t

time only

ts

timestamp (time + date)

constant_value
Is the value of the escape sequence. constant_value must follow these formats for each literal_type.

d

yyyy-mm-dd

t

hh:mm:ss[.fff]

ts

yyyy-mm-dd hh:mm:ss[.fff]

Note that the specification is very clear that the d is date only; the t is time only; and the ts is both.

Unexpected writeOutput() and <cfoutput> difference

G'day:
Sorry, mentioned this on Twitter a few days ago now:

Today I learned that writeOutput() is not a direct analogy of <cfoutput> for simple expressions. And now I hate #CFML that tiny bit more.
— Adam Cameron (@dacCfml) January 13, 2014

...but not finding any time for writing at the moment. I'll make a start, and see how far I get.

ColdFusion 10 Update 13: "This update introduces support for OS X 10.9 Mavericks"

G'day:
Just a heads-up for you Mac users out there who have been caught out by issue 3653076 "Bad apache / tomcat connector for Mac OSX Mavericks 10.9".

Adobe just posted this: "ColdFusion 10 Update 13 released", and this includes the fix for the Mavericks thing.

I have not attempted to install the updater yet. Let us know how you get on with it.

Update:

I have now. Please note that the fix for 3653076 is the only fix in this update. Which is pretty bloody disappointing, actually!

--
Adam

Suggested trivial changes to the Adobe ColdFusion bug tracker

G'day:
This is more just a list of stuff for Rakshith's attention than anything relevatory. There's a few small tweaks to the bug tracker which would be useful.

Help me understand how a CFML REST request should not cause onCfcRequest() to fire

G'day:
I have to admit I am not very au fait with the idiosyncrasies of REST requests. To me a REST request is just... a request. The difference being the mechanism at the other end is more likely to respect verbs other than GET and POST like normal browser-based requests make, and they return "data" rather than mark-up. But other than that: there's nothing really to them. It's more a concept / strategy than anything else.

In this light, a while back I noticed that a REST request I was making didn't fire the associated onCfcRequest() event handler, as documented here: "REST requests don't seem to correctly use Application.cfc either". I duly raised a ticket: 3590745.

Rupesh has come back with this:

OnCFCRequest is meant for the requests which are made directly to the CFC - as AJAX request or directly over HTTP. For Rest request or web service or web socket requests, CFC happens to be an end point to a request (where the CFC is not explicitly invoked) and therefore OnCFCRequest is not called for these three types of requests.

I understand what he's saying, but to me - as I say in my follow-up - what he says seems like an example of post hoc ergo propter hoc. Basically the conclusion drawn is not implied by the supporting information. Here's what I said in response:

(2/4) ColdFusion: var hoisting can make a difference

G'day:
Remember a while back I observed that - like JavaScript - ColdFusion hoists its VAR declarations: "ColdFusion hoists VAR declarations". At the time I could not see how this could cause problems in CFML. Well I've noted a case where it does cause problems, in that it reveals a bug in ColdFusion 9 & 10.

I came across this ticket on the bug tracker: "cfloop array and wrong iterator", which details how ColdFusion 9 (and, as it turns out: 10) gets confused whilst array-looping in an edge-case situation. Check this out:

(1/4): it's not all about ColdFusion 10 bugs. CF 9.x has outstanding bugs too...

G'day:
First the "1/4" thing. Matt Bourke has just challenged me to release another four blog articles today. Let's see if I can do it. I make no apologies for the quality (or length) of the writing today. I'm not in the pub for one thing ;-)

This one is really short, but was underway before Matt challenged me.

Glitch in ColdFusion's CFML parser

G'day:
This is not what I was meaning to write about today, but hey.

I'm on the second leg of my trip to Galway: Central Line › Piccadilly Line (which today is taking on some of the District Line stations too, just - I think - to make my journey even more shit) › sit around at LHR drinking Guinness (or waiting in the security queue, depending on how busy it is... it'll be busy, I reckon) › fly to Shannon › bus to Galway › another bus to the bit of Galway I actually want to go to. This'll all take about 7h. Bleah. I'm catching a bus today because the rental car rates were insane this weekend. Instead of the usual £50 for two days, Hertz wanted close to £300 for three days. I cannot afford that. So I'm busing (€20) to Galway, and catching a cab (€100) back on Mon. Anyway, the point being I've got a lot of time sitting around, so I'm "investigating".

Right... I don't want this to become to blogs what CFHour is to podcasts (50% waffle before it gets going), so... erm... CFML stuff...

CFML: Quicky: another feed going to @CfmlNotifier

G'day:
If you follow @CfmlNotifier on Twitter (and if yer a CF developer, you should be!), you'll note I've started another feed to it, reporting along the lines of:

2014-04-05 14:36 Untriaged ColdFusion 10 bug count: 61. List: http://t.co/XGoReqPrfq
— CfmlNotifier (@CfmlNotifier) April 5, 2014

I'm doing a status update on that every six hours 24 hours. It'll be interesting to see how the count changes. Due to how Twitter works, if I duplicate a status message (eg: in six hours time there's still 87 untriaged ColdFusion 10 bugs), the latter update will possibly be marked as a duplicate and not sent. I think this is OK: "no news is... well, not good news, but at least the status quo".

Hopefully you find this at least mildly informative.

And don't forget to vote for bugs that affect you, or if you need to give Adobe further information (like "why did you close this ticket saying 'never fix'? It's a right sball-ache for me!"). They do listen.

FYI, the count was over 100 a coupla days ago, so they do seem to be doing some triage at the moment. So that's good news. And it's certainly an improvement from when I wrote this: "212 untriaged ColdFusion 10 bugs" (back in May). Good work Adobe, but... hey... there's still quite a way to go, eh? All this stuff should be triaged already. They don't need to be fixed, but they should be triaged as soon as they're raised. Not months / years later.

Oh, and I know I've been a bit quiet this week (on the blog, anyhow). Work's been busy, and I've been a bit crook with a cold, so just watching telly in the evenings. I've got a coupla articles on the go, I just need the code sorted out.

Righto.

--
Adam

CFML weirdness with chr(0)

G'day:
I was trying to help someone on Stack Overflow y/day with their question "How to pad a string with null/zero-bytes in ColdFusion & difference between CF on MacOS and Windows". The question is actually shorten than the title: how to add null characters to a string in CFML.

I thought the answer was a simple "use chr(0)", but this turned out to not be a viable answer on ColdFusion (or Railo for that matter).

In response to my suggestion, Stack Overflow veteran Leigh made the observation "Unfortunately no. The character just disappears. But URLDecode("%00") will generate a single null byte". I've not known Leigh to be wrong so I didn't doubt him, but that sounded really odd, so I decided to check it out.

<!--- baseline.cfm --->
<cfset s = "test" & chr(0)>
<cfoutput>
string: [#s#]<br>
length: [#len(s)#]<br>
</cfoutput>

And the - surprising to me - output:

string: [test]
length: [4]

Um... where gone?

I tried this on Railo... thinking Railo's more likely to get it right than CF is, and it had the same output. Testing on OpenBD got what I'd consider to be the correct results:

string: [test]
length: [5]

The NULL isn't printable, so doesn't render anything, but it should still actually be there, and that string should consist of five bytes: 0, 116, 101, 115, 116. That's a length of five. As per OpenBD's output.

That said, I know that NULLs do have special meaning in some strings, for example C has the concept of a null-terminated string, in which the null signifies the end of the string, not a character in the string. I wasn't aware of this being a "thing" in Java, but maybe it was.

I refined my code somewhat to not be simply end-padding the string:

<!--- outputStringContainingChr0.cfm --->
<cfset s = chr(0) & "foo#chr(0)#">
<cfoutput>#s#:#len(s)#:#asc(left(s,1))#</cfoutput>

So I'm sticking a NULL at the beginning and end of the string. If it was acting as a terminator, s would simply be an empty string afterwards. But I get this (CF and Railo both):

foo:3:102

102 is indeed the ASCII code for f.


So what's the story here? I still had a suspicion that something "non-stupid" was happening here, and I just didn't get it. Maybe there's something about a NULL char's standard handling that means it's not added to strings. Although this seems far-fetched as obviously there's use-cases for it (see the Stack Overflow question), and indeed Leigh came up with the fudged way to do it:

Closed/deferred/NotEnoughTime, eh?

G'day:
I was goaded (OK, not really) into this by some observers on IRC. This is in regards to ticket number 3123145.

Adobe, you really don't "get" how client-liaison works, do you?

Ways to call functions in CFML

G'day:
We've got Brad Wood and David Epler to thank for this article (sorry that Twitter presents information back to front, so start at the bottom and read up. Like one never generally would):

CFML function syntax

Locking investigation for Brad

G'day:
I will admit I'm not in a blog mood at the moment, hence the silence over the last few days. However Brad Wood has asked for a second set of eyes on some code of his, so here are my findings.

Follow-up: ColdFusion support for OSX 10.9 - fixed

G'day:
Very quickly... I've talked about this twice:

• "So there won't be support for OSX 10.9 "Mavericks" on ColdFusion 10"
• "Adobe backtracks on no-support for ColdFusion 10 on OSX 10.9"

Pleasingly... this issue (3653076) is now marked "fixed/to test" on the bug tracker.

Adobe backtracks on no-support for ColdFusion 10 on OSX 10.9

G'day:
I mentioned this the other day: 'So there won't be support for OSX 10.9 "Mavericks" on ColdFusion 10'. I just checked the bug tracker, and ticket 3653076 has now been marked "To Fix". Hopefully they mean "for ColdFusion 10" (and, realistically, they should fix it in CF9 too, as it's still a supported version of ColdFusion), not just for ColdFusion 11.

Good work to two groups of people:

• the community, for rounding on this issue and making their voices heard. The ticket's only existed for three days, but it's got 33 votes and 20 comments. That's very active for a ColdFusion issue;
• the Adobe ColdFusion team for seeing sense in this matter.

Yay everyone!

--
Adam

So there won't be support for OSX 10.9 "Mavericks" on ColdFusion 10

G'day:
There's been a huge flurry of activity on the ColdFusion Bug tracker around ticket 3653076, entitled "Bad apache / tomcat connector for Mac OSX Mavericks 10.9". It was raised two days ago and has 20 votes already, and 13 comments.

And Richard Herbert has just done the decent thing and reminded us all that Adobe have already officially responded to this...

Follow-up to a "not a bug" status from Adobe: arrayFindNoCase() returns false negatives

G'day:
About a year ago I raised a ticket observing that arrayFindNoCase() doesn't really work so reliably: 3316776. A coupla weeks ago it was marked as "not a bug", which I find rather bemusing - as there's definitely buggy behaviour - but not as bemusing as the explanatory feedback from Adobe.

"Not worth the effort" again, from the Adobe ColdFusion team

G'day:
Andrew Scott brought this one to my attention. It's what seems to be another example of Adobe finding the "too hard basket" being more convenient that rolling up one's sleeves and actually doing one's job properly.

ColdFusion: Tirade averted... (update: no, actually: tirade)

G'day:
Last night someone from the community directed me at this issue on the bugbase: "Updating a task via cfschedule resets task to defaults". Neither of us could believe what Adobe had said to justify themselves. Fortunately in the interim cooler heads have prevailed, and they're on the case, but - dammit - I want to mention this anyhow.

The story with this bug - and it's a bug, Uday - is this:

If you are updating a scheduled task via the cfschedule tag it is possible for some of the task info to be reset back to default. For example, if task had an eventhander configured and cfschedule was used to update task but eventhandler attribute was not used then eventhandler would be set to blank. The eventhandler attribute is just one example as this affects other attributes equally.

So that's a bit rubbish.

Last night, the response from Adobe - via Uday Ogra - was this:

This is by design. As this action re-creates the schedule task. For updating particular attributes of an existing task it is recommended to use admin UI

This is yet another example of Adobe people being bloody jobsworths, IMO. I am gobsmacked by the stunning ignorance of Uday's justification here on two levels:

• Who cares if it's by design: it's poor, lazy design. I'd be cool with this is Adobe went "oh yeah... oops", but to try to justify this away with "oh, it's meant to be like that" is pathetic. Indeed if you actually went out of your way to design something like that it doubles the question marks over your capabilities here: introducing a bug during development is one thing; specifically deciding to design something this poorly is unbelievable. Do you mean to say you sat down and went "right, when one uses this functionality to do an update, we'll blow away all the settings to didn't specifically set for update. Yeah: that's what people will want". Shudder.
• What sort of bloody moronic advice is "as an alternative, use the UI". How is that gonna help us in our code? What sort of completely detached from reality suggestion is that? How is it a solution to a coding problem to suggest "use the UI instead".

... although Adobe seems to have fixed their own notifications on the bug tracker

G'day:
I buried this at the bottom of my previous article, but on reflection it's pretty good news in and of itself, so I'll elevate it to its own quick article.

The Adobe bug tracker seems to have started sending out update notifications at last!